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

[Christopher Schmidt]

On Tue, Oct 09, 2007 at 03:39:21PM +0100, Martin Daly wrote:
> > 1. Coordinate order should respect EPSG (esp. geographic in crs)
> 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.

I agree that this represents the "will of the people".

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

Yeah, I have no problem with that. As it stands, I don't really care,
but I understand the desire to make GeoJSON match up to other things :) 

> > 3. GeometryCollection-s should be allowed to own any geometry type,
> > including other GeometryCollection-s.
> 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).

I don't think that the existing GeoJSON spec actually prevents this.
(It's another case where it's probably not going to be used/supported by
any GeoJSON producers/consumers, however.)

> > 4. Demote Box to a special case
> 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.

I think that having Box is one of the things that people-other-than-me
were for. I'm perfectly happy with dropping it, but would like similar
feedback from others. (Remeber that a Box is just a special case of
Polygon.) 

> > 5. The feature model should not require a geometry member, and
> > should treat it as "just another property".
> 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?

This is part of it. There's also the fact that with geometry as 'just
another attribute' there's actually nothing to distinguish GeoJSON
Features from anything else. If you want to put Geometry inside some
other JSON attribute, you can do that, and it's still a GeoJSON
geometry, but it's not a GeoJSON Feature.  

Regards,
-- 
Christopher Schmidt
MetaCarta