[Geojson] GeoJSON, OGC, ISO and everything in between

[Martin Daly]

John Herring raised concerns about GeoJSON-s divergence from OGC SF, ISO 19107 and ISO 19109, and there has been some (at times baffling) correspondence since.

Reading John's document, his concerns seem to be:

1. Coordinate order should respect EPSG (esp. geographic in crs)

2. Geometry definitions should be more explicit, for completeness, e.g. "The interpretation of a point is the single location described by the coordinate.", Polygon ring ordering, no self intersections, etc.

3. GeometryCollection-s should be allowed to own any geometry type, including other GeometryCollection-s.

4. Demote Box to a special case

5. The feature model should not require a geometry member, and should treat it as "just another property".

So, here goes.

1. has come up time and again, and my impression of the settled will of the group is that the target audience for GeoJSON is not axes-order aware, and so EPSG crs-s with axes order other than lon/lat (that means none of the geographic) or easting/northing (that means a significant minority of the projected) are forbidden by the spec.  The intention was, I think, to remove ambiguity for the EPSG-naïve.

2. Seems a good idea to me, but in another section of the spec, linked from the "this is how to encode in JSON" part.  These definitions are not related to the JSON encoding, but, as John says, are worth restating for those unfamiliar with, e.g. ISO 19107.

3. Yuck.  I never liked this in SF either, but, if it has to be, then fine (we'll never produce them, and we will flatten them if we receive them, so tough).

4. Box seems useful to me (and to Oracle Spatial, which has a special SDO_GEOMETRY construct for it...), but moving it to outside the main Geometry definitions also makes sense.

5. I think that this restriction arises directly from the lack of a JSON description language, e.g. an equivalent of XML Schema, and is intended to make it easy for the receiver to discern where the Geo bit of GeoJSON is.  Also, after turning GeoJSON into a JavaScript variable, it is simpler to know the name of the geometry part of the object.  Would noting this as a divergence from the feature model, and explaining why, be a satisfactory resolution?

M