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

[Jason Birch]

Nice recap Martin.

Here's my take:

1. I don't care if GeoJSON forces an x/y interpretation of coordinates.  I found it interesting that John's email read right-to-left in my webmail :)

2. Sure; the wiki's open.

3. Uh, that sounds painful...

4. No opinion

5. This is a pet "want" of mine.  I would prefer to see geometry be a pointer to the name of the "default" geometry property, and allowing 0:many geometry properties.  It's a requirement for the JSON support in MapGuide's RESTful feature representation (via FDO) that Haris Kurtagic is working on, and it means that he has to use a subset of GeoJSON or possibly even something that's not GeoJSON at all.

I think that it's pretty clear that in order for GeoJSON to fully support representation of Oracle (or PostGIS, or FDO) feature classes, it would need to be extended.  I think it's also clear that current users (and drivers) of the pragmatic GeoJSON spec don't require a format more complicated than a basic shapefile.

Does this mean that GeoJSON is useless?  Absolutely not.  But it does mean that there will either need to be a version 2, or that traditional GIS implementations will go their own way and not be able to use GeoJSON in a way that is universally consumable.

Jason 

-----Original Message-----
From: Martin Daly
Subject: [Geojson] GeoJSON, OGC, ISO and everything in between

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