[OASIS Issue Tracker] Commented: (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>]

    [ http://tools.oasis-open.org/issues/browse/ODATA-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=36761#action_36761 ] 

Stefan Drees commented on ODATA-596:
------------------------------------

Given that OData ATOM format fell back behind core and JSON progress (not enough claimed usage for becoming a standard also) I tend to see these impedance mismatches w.r.t. mixing in additional domain specific languages more like further entries on a drop list (which is growing) of full equivalence of the formats. So here we might be better of - like with the updated JSON RFC which obsoletes the old one - that we note in the ATOM format descriptions interoperability notes, that place a nice SHOULD to avoid usage of this assumed flexibility on the side of GML to maximize interoperability. 
 
Coordinate transforms on the client side are hard as you describe in the last paragraph and often were never really feasible given the need in space (keep all refs) and power (calculating the mappings) for most clients. From my understanding this bad impedance match (leaving the resolution here with the client, to have in theory some more flexible representation in the data) was one of the major reasons, GeoJSON came into existence  and accumulated such a large following.

On a formal side, I kindly suggest we switch to more and more reference for GeoJSON the internet draft http://www.ietf.org/id/draft-butler-geojson-01.txt (current revision) as this is the GeoJSON standard on its way to an RFC.

> 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