[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (ODATA-965) UpdateGeoJSON Reference to RFC7946
[ https://issues.oasis-open.org/browse/ODATA-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Hagen updated ODATA-965:
-------------------------------
Description:
The GeoJSON community submitted it's standard as an internet draft to IETF.
This lead to the foundation of the IETF Geographic JSON Working Group (https://datatracker.ietf.org/wg/geojson/charter/).
As of August, 11 2016 the GeoJSON specification now is the RFC 7946 (on the internet standards track).
We should reference this one instead of the intermediate draft (after evaluation of the changes cited below from the RFC, Appendix B):
Appendix B. Changes from the Pre-IETF GeoJSON Format Specification
This appendix briefly summarizes non-editorial changes from the 2008
specification [GJ2008].
B.1. Normative Changes
o Specification of coordinate reference systems has been removed,
i.e., the "crs" member of [GJ2008] is no longer used.
o In the absence of elevation values, applications sensitive to
height or depth SHOULD interpret positions as being at local
ground or sea level (see Section 4).
o Implementations SHOULD NOT extend position arrays beyond 3
elements (see Section 3.1.1).
o A line between two positions is a straight Cartesian line (see
Section 3.1.1).
o Polygon rings MUST follow the right-hand rule for orientation
(counterclockwise external rings, clockwise internal rings).
o The values of a "bbox" array are "[west, south, east, north]", not
"[minx, miny, maxx, maxy]" (see Section 5).
o A Feature object's "id" member is a string or number (see
Section 3.2).
o Extensions MAY be used, but MUST NOT change the semantics of
GeoJSON members and types (see Section 6).
o GeoJSON objects MUST NOT contain the defining members of other
types (see Section 7.1).
o The media type for GeoJSON is "application/geo+json".
B.2. Informative Changes
o The definition of a GeoJSON text has been added.
o Rules for mapping 'geo' URIs have been added.
o A recommendation of the I-JSON [RFC7493] constraints has been
added.
o Implementers are cautioned about the effect of excessive
coordinate precision on interoperability.
o Interoperability concerns of GeometryCollections are noted. These
objects should be used sparingly (see Section 3.1.8).
was:
The GeoJSON community submitted it's standard as an internet draft to IETF.
This lead to the foundation of the IETF Geographic JSON Working Group (https://datatracker.ietf.org/wg/geojson/charter/).
As of August, 11 2016 the GeoJSON specification now is the RFC 7946 (on the internet standards track).
We should reference this one instead of the intermediate draft (after evaluation of the changes):
Appendix B. Changes from the Pre-IETF GeoJSON Format Specification
This appendix briefly summarizes non-editorial changes from the 2008
specification [GJ2008].
B.1. Normative Changes
o Specification of coordinate reference systems has been removed,
i.e., the "crs" member of [GJ2008] is no longer used.
o In the absence of elevation values, applications sensitive to
height or depth SHOULD interpret positions as being at local
ground or sea level (see Section 4).
o Implementations SHOULD NOT extend position arrays beyond 3
elements (see Section 3.1.1).
o A line between two positions is a straight Cartesian line (see
Section 3.1.1).
o Polygon rings MUST follow the right-hand rule for orientation
(counterclockwise external rings, clockwise internal rings).
o The values of a "bbox" array are "[west, south, east, north]", not
"[minx, miny, maxx, maxy]" (see Section 5).
o A Feature object's "id" member is a string or number (see
Section 3.2).
o Extensions MAY be used, but MUST NOT change the semantics of
GeoJSON members and types (see Section 6).
o GeoJSON objects MUST NOT contain the defining members of other
types (see Section 7.1).
o The media type for GeoJSON is "application/geo+json".
B.2. Informative Changes
o The definition of a GeoJSON text has been added.
o Rules for mapping 'geo' URIs have been added.
o A recommendation of the I-JSON [RFC7493] constraints has been
added.
o Implementers are cautioned about the effect of excessive
coordinate precision on interoperability.
o Interoperability concerns of GeometryCollections are noted. These
objects should be used sparingly (see Section 3.1.8).
> UpdateGeoJSON Reference to RFC7946
> ----------------------------------
>
> Key: ODATA-965
> URL: https://issues.oasis-open.org/browse/ODATA-965
> Project: OASIS Open Data Protocol (OData) TC
> Issue Type: Improvement
> Components: OData JSON Format
> Affects Versions: V4.01_WD01
> Environment: [Proposed]
> Reporter: Stefan Hagen
> Priority: Minor
>
> The GeoJSON community submitted it's standard as an internet draft to IETF.
> This lead to the foundation of the IETF Geographic JSON Working Group (https://datatracker.ietf.org/wg/geojson/charter/).
> As of August, 11 2016 the GeoJSON specification now is the RFC 7946 (on the internet standards track).
> We should reference this one instead of the intermediate draft (after evaluation of the changes cited below from the RFC, Appendix B):
> Appendix B. Changes from the Pre-IETF GeoJSON Format Specification
> This appendix briefly summarizes non-editorial changes from the 2008
> specification [GJ2008].
> B.1. Normative Changes
> o Specification of coordinate reference systems has been removed,
> i.e., the "crs" member of [GJ2008] is no longer used.
> o In the absence of elevation values, applications sensitive to
> height or depth SHOULD interpret positions as being at local
> ground or sea level (see Section 4).
> o Implementations SHOULD NOT extend position arrays beyond 3
> elements (see Section 3.1.1).
> o A line between two positions is a straight Cartesian line (see
> Section 3.1.1).
> o Polygon rings MUST follow the right-hand rule for orientation
> (counterclockwise external rings, clockwise internal rings).
> o The values of a "bbox" array are "[west, south, east, north]", not
> "[minx, miny, maxx, maxy]" (see Section 5).
> o A Feature object's "id" member is a string or number (see
> Section 3.2).
> o Extensions MAY be used, but MUST NOT change the semantics of
> GeoJSON members and types (see Section 6).
> o GeoJSON objects MUST NOT contain the defining members of other
> types (see Section 7.1).
> o The media type for GeoJSON is "application/geo+json".
> B.2. Informative Changes
> o The definition of a GeoJSON text has been added.
> o Rules for mapping 'geo' URIs have been added.
> o A recommendation of the I-JSON [RFC7493] constraints has been
> added.
> o Implementers are cautioned about the effect of excessive
> coordinate precision on interoperability.
> o Interoperability concerns of GeometryCollections are noted. These
> objects should be used sparingly (see Section 3.1.8).
--
This message was sent by Atlassian JIRA
(v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]