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

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).