[OASIS Issue Tracker] Created: (ODATA-596) Discrepancy between order of elements for geo-positions between GeoJSON and GML may cause interoperability difficulties.

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

Discrepancy between order of elements for geo-positions between GeoJSON and GML may cause interoperability difficulties.
------------------------------------------------------------------------------------------------------------------------

                 Key: ODATA-596
                 URL: http://tools.oasis-open.org/issues/browse/ODATA-596
             Project: OASIS Open Data Protocol (OData) TC
          Issue Type: Improvement
          Components: OData ATOM Format , OData JSON Format
    Affects Versions: V4.0_OS
            Reporter: Evan Ireland
             Fix For: V4.0_ERRATA01


JSON format uses GeoJSON for geo-types. GeoJSON states:

  http://geojson.org/geojson-spec.html#positions

  The order of elements must follow x, y, z order (easting, northing, altitude for coordinates in a projected coordinate reference system, or longitude, latitude, altitude for coordinates in a geographic coordinate reference system).

ATOM format uses GML, which seems to permit the order of elements to depend on the CRS definition. For example, with SRID 4326 (the default for geography types) , GML puts latitude before longitude (i.e. in the opposite order to what GeoJSON would dictate).

Now this presents some difficulties for clients (and proxy servers which wish to switch the format). Suppose we wish to define an OData client API which encapsulates the format (ATOM or JSON) entirely under the covers. Suppose we then receive a GeographyPoint (some API abstraction of a point, which is format neutral) from a server. With JSON format, the client API will be able to guarantee in which order longitude and latitude appear in GeographyPoint (since GeoJSON dictates it). On the other hand, for ATOM (GML) the order of elements may depend on the CRS. This might lead one to conclude that an ATOM-format consuming client needs a full database of SRIDs, together with rules about element order, so it can receive geo-values over ATOM and give a predictable ordering of the coordinate elements within the client API (such that the element order would not change if the OData format is changed from ATOM to JSON).



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira