Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pull some plugs, remove unused references and intermediate notes and minor edits #10

Closed
wants to merge 2 commits into from
Closed

Pull some plugs, remove unused references and intermediate notes and minor edits #10

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
e6c26a1
prepare plug-pull-request by removing all discussion notes from sdree…
May 20, 2013
034e766
renamed the single copies per GeoJSON example in the document to trig…
Jun 14, 2013
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion CHANGES.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,5 @@
20130614 - renamed the single copies per GeoJSON example in the document to trigger the new GeoJSON display rendering on github
20130402 - reduced crsRef to single label with domain RFC 5165 like URN, thus renamed it to crsURN
20130430 - moved repo to GeoJSONWG organization at https://github.com/GeoJSONWG/draft-geojson
20130428 - typos corrected, editorial changes throughout the document and several notes partly explaining thes or requesting further changes or additions. Correction of inconsistent may in GeoJSON Object first list item into MUST, merge with second listitem and provision of js and bib folders
20130427 - initial draft
20130427 - initial draft
3 changes: 3 additions & 0 deletions js/README.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,3 +2,6 @@ These are the example sources for the middle and back part of the draft
rfc to ease consistent formatting and syntax checking. Edits should be
performed on these files and then copied into the ../middle.mkd and
../back.mkd respectively to not loose revisions.
The extension has been changed from .js to .geojson as a) these are GeoJSON samples
and b) to test the new github feature automatically rendering a nice display in the users browser
for files ending in .geojson.
0 js/example_01.js → js/example_01.geojson
View file
Open in desktop
File renamed without changes.
0 js/example_02_a.js → js/example_02_a.geojson
View file
Open in desktop
File renamed without changes.
0 js/example_02_b.js → js/example_02_b.geojson
View file
Open in desktop
File renamed without changes.
0 js/example_appendix_01.js → js/example_appendix_01.geojson
View file
Open in desktop
File renamed without changes.
0 js/example_appendix_02.js → js/example_appendix_02.geojson
View file
Open in desktop
File renamed without changes.
0 js/example_appendix_03_a.js → js/example_appendix_03_a.geojson
View file
Open in desktop
File renamed without changes.
0 js/example_appendix_03_b.js → js/example_appendix_03_b.geojson
View file
Open in desktop
File renamed without changes.
0 js/example_appendix_04.js → js/example_appendix_04.geojson
View file
Open in desktop
File renamed without changes.
0 js/example_appendix_05.js → js/example_appendix_05.geojson
View file
Open in desktop
File renamed without changes.
0 js/example_appendix_06.js → js/example_appendix_06.geojson
View file
Open in desktop
File renamed without changes.
0 js/example_appendix_07.js → js/example_appendix_07.geojson
View file
Open in desktop
File renamed without changes.
92 changes: 2 additions & 90 deletions middle.mkd
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -56,27 +56,12 @@ content deemed irrelevant by the authors and at that point. These
placeholders must of course be deleted or otherwise replaced, before
attempting to validate the corresponding JSON code example.

Note-sdrees: The second and third paragraph of this section have been
added, to not forget to satisfy the need of issueing structural
constraints with strong impact on interoperability (but not necessarily
at this place or in this form).

## Definitions

* JavaScript Object Notation (JSON), and the terms object, name, value,
array, number, true, false, and null are to be interpreted as
defined in [RFC4627].

* The Hypertext Transfer Protocol (HTTP) is defined in [RFC2616].

* Transport Layer Security (TLS) is defined in [RFC5246].

* Hypertext Transfer Protocol Over TLS (HTTPS) is defined in [RFC2818].

* The Uniform Resource Identifier (URI) is defined in [RFC3986].

* The Uniform Resource Name (URN) is defined in [RFC5165].

* Inside this document the term geometry types refers to the seven
case-sensitive strings: "Point", "MultiPoint", "LineString",
"MultiLineString", "Polygon", "MultiPolygon", and
Expand All @@ -93,31 +78,6 @@ at this place or in this form).
* When using the term interior geometric shape it is assumed that
there exists an exterior shape.

Note-sdrees: The last four items in the list above are added, to not
forget to satisfy the need of defining these terms (but not necessarily
at this place or in this form).

Note-sdrees: We should consider adding at least an optional member
on the top-level GeoJSON object with name "namespace" and a value
of say "http://geojson.org/ns/geojson" or maybe something (after
acceptance by the IETF like "http://docs.ietf.org/ns/rfc9876"
hypothetically assuming this ends up as RFC9876) but then we might have
also to adapt the "no action needed from IANA section".
Then we might somewhere have a section "Namespace" explaining it in
general and amend its usage with:

* The namespace member SHOULD be on the top-level GeoJSON object in the
following canonical hierarchical ordering, i.e. if present on a
feature collection, else if present on a feature, else on a geometry
and MUST NOT be repeated or overridden on children or
grandchildren of the object.

Motivation for above proposal: The benefit would be, that we a) remain
backwards compatible, but b) avoid future clashes with JSON of unclear
provenance when consuming in a client. Alternatively one might
prefix all wonderful type names with say "geo" and a dot or so (not
preferred) or even the names of the members (shiver).

## Example

A GeoJSON feature collection:
Expand Down Expand Up @@ -189,13 +149,9 @@ referred to as the GeoJSON object in this document.
value - additional rules apply, then these are stated in the
following sections where each type is further defined.

* A GeoJSON object MAY have an optional "crsURN" member. If it is present,
the value of it MUST be a valid coordinate reference system reference
(see "[3. Coordinate Reference System (CRS) Reference](rfc.section.3)").

* A GeoJSON object MAY have a "bbox" member. If it is present,
the value of it MUST be a bounding box array (see
"4. Bounding Box").
"3. Bounding Box").

## Geometry Object

Expand Down Expand Up @@ -229,10 +185,6 @@ Any number of additional elements are allowed -- interpretation and
meaning of additional elements is beyond the scope of this
specification.

GeoJSON data producers MAY indicate a different sense of the position
elements by including a "crsURN" object in the position's context. See
the Coordinate Reference System section below for details.

Examples of positions and geometries are provided in "Appendix A.
Geometry Examples".

Expand Down Expand Up @@ -265,8 +217,7 @@ the concept of a linear ring (LinearRing):
* The first and last positions are equivalent (they represent
equivalent points).

Though a LinearRing is not explicitly represented as a GeoJSON geometry
type, it leads to a canonical formulation of the Polygon geometry type
This leads to a canonical formulation of the Polygon geometry type
definition as follows:

* For type "Polygon", the "coordinates" member MUST be an array of
Expand Down Expand Up @@ -313,45 +264,6 @@ An object of type "FeatureCollection" MUST have a member with the name
"features". The value corresponding to "features" is an array. Each
element in the array is a feature object as defined above.

# Coordinate Reference System (CRS)

The coordinate reference system of a GeoJSON object and the sense of
coordinate order is determined by the value of its "crsURN" member
(referred to as the CRS reference below). If an object has no crsURN
member, then its parent or grandparent object's crsURN member may be
acquired. If no crsURN member can be so acquired, the default CRS shall
apply to the GeoJSON object.

* The default CRS is a geographic coordinate reference system, using
the WGS84 datum, and with longitude and latitude units of decimal
degrees. In an array of coordinate values, longitude is first and is
followed by latitude.

* The value of a member named "crsURN" must be a string (referred to
as the CRS reference below) or JSON null. If the value of "crsURN" is
null, no CRS can be assumed. Note-sdrees: FIXME or default CRS as
when crsURN member is left out? It is optional anyway.

* The crsURN member SHOULD be on the top-level GeoJSON object in the
following canonical hierarchical ordering, i.e. if present on a
feature collection, else if present on a feature, else on a geometry
and MUST NOT be repeated or overridden on children or
grandchildren of the object.

Note-sdrees: The name has been changed from crs to crsURN to not
irritate consumers that expect the crs object as of version 1.0 in the
community spec.

If present the CRS reference MUST indicate a coordinate reference
system by name. In this case, the value of it MUST be a string
identifying a coordinate reference system. OGC CRS URNs such as
"urn:ogc:def:crs:OGC:1.3:CRS84" SHALL be preferred over legacy
identifiers such as "EPSG:4326":

"crsURN": "urn:ogc:def:crs:OGC:1.3:CRS84"

For the format of a valid URN cf. [RFC5165].

# Bounding Box

A GeoJSON object MAY have a member named "bbox" to include information
Expand Down
17 changes: 3 additions & 14 deletions template.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,12 +4,7 @@
<!ENTITY pandocBack PUBLIC '' 'back.xml'>

<!ENTITY pandocRef2119 PUBLIC '' 'bib/reference.RFC.2119.xml'>
<!ENTITY pandocRef2616 PUBLIC '' 'bib/reference.RFC.2616.xml'>
<!ENTITY pandocRef2818 PUBLIC '' 'bib/reference.RFC.2818.xml'>
<!ENTITY pandocRef3986 PUBLIC '' 'bib/reference.RFC.3986.xml'>
<!ENTITY pandocRef4627 PUBLIC '' 'bib/reference.RFC.4627.xml'>
<!ENTITY pandocRef5165 PUBLIC '' 'bib/reference.RFC.5165.xml'>
<!ENTITY pandocRef5246 PUBLIC '' 'bib/reference.RFC.5246.xml'>
]>

<rfc ipr="trust200902" category="info" docName="draft-sdrees-geojson-format-spec-01">
Expand Down Expand Up @@ -64,7 +59,7 @@
</address>
</author>
-->
<date month="April" year="2013"/>
<date month="May" year="2013"/>

<area>General</area>
<workgroup>Independent</workgroup>
Expand All @@ -86,7 +81,8 @@
<middle>
&pandocMiddle;
<section title="Security Considerations">
<t>This memo raises no security issues.</t>
<t>This specification has the same security considerations as
JSON [RFC4627].</t>
</section>
<section title="IANA Considerations">
<t>This document has no actions for IANA.</t>
Expand All @@ -96,14 +92,7 @@
<back>
<references title="Normative References">
&pandocRef2119;
&pandocRef2616;
&pandocRef2818;
&pandocRef3986;
&pandocRef4627;
&pandocRef5165;
</references>
<references title="Informative References">
&pandocRef5246;
</references>
&pandocBack;
</back>
Expand Down