OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

[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:comment-tabpanel&focusedCommentId=63676#comment-63676 ] 

Stefan Hagen commented on ODATA-965:

Assigned issue to me to validate changes against the parts referenced to by our work products.

> 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
>            Assignee: Stefan Hagen
>            Priority: Minor
>             Fix For: V4.01_WD01
> 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]