Topic: Use GeoJSON

The GeoJSON format is quite popular on the web. The OGC may want to adopt the format. However, while the format could be quite useful for OGC services, the OGC cannot adopt GeoJSON without modification because GeoJSON has an ambiguous axis order policy which conflicts with OGC rules regarding axis orders. That ambiguity makes the format unsuitable for use as a general purpose spatial data format. In order to use GeoJSON, the OGC would have to develop a profile which would

• require GeoJSON processors to check the CRS and adopt processing based on the manifold of the coordinate system, and
• restrict the allowed CRS to CRSs with axes which can be unambigously mapped to 'east' and 'west'.

Additional comment(s): OldTechnicalDiscussions

Relations to other topics

Related to Topic

Discussion

Seems the best way forward for the community at large is: team up with the GeoJSON developers, explain the obvious shortcomings, collaborate on improvements. Coupling axis order to the CRS makes a lot of sense and is in coherence with the OGC Name Type Definition BP, so clearly defined = good to explain and to implement; OGC members might implement JS snippets performing CRS inspection (OWS?). All other alternatives (competing spec, restrictions to 2D, ...) IMHO will fail on the long run for diverse reasons.

-- PeterBaumann - 30 Jun 2013

---

From what I understand, the group of individuals responsible for producing the GeoJSON specification is completely uninterested in changing any part of the specification. Since section 2.1.1 explicitly states that coordinates must be in X,Y,Z order, valid GeoJSON is restricted to CRSs such as urn:ogc:def:crs:OGC:2:84 that use this order. The OGC community must decide whether this restriction is acceptable despite the fact that it directly contradicts ISO6709 and accepted practice in most safety-of-life domains.

-- JeffYutzler - 11 Dec 2013

I find it odd that a fixed encoding order is considered more ambiguous than a variable one where the order is determined by external data. The implication of this is that in order to correctly interpret a file you need to know what the definition of the CRS is in the first place. I understand that it's desirable to respect CRS defined axis order for display purposes in user interfaces, but I don't see any good reason to this at the encoding level as well.

-- PepijnVanEeckhoudt - 16 Jan 2014