Rethinking JSON for Geospatial

My issues with the specification coming together at are orthogonal to Matt Giger's. Lists are the closest thing in JSON to tuples, and are the right way to represent points within lines and rings. The semantics of GeoJSON's:

[ [x1, y1, z1], ..., [xn, yn, zn] ]

are pretty obvious and the structure doesn't have to be unpacked like Matt's:

[ x1, y1, z1, ..., xn, yn, zn ]

Should you represent geometries as lists of lists in your analysis or visualization software? Probably not, for the reasons that Matt mentions: memory overhead and speed of access. But we're just talking about the wire format here, and representational clarity trumps computational efficiency on the Web. Limitations or quirks of our implementations shouldn't be engraved into our standards.

Which brings me to my issues with GeoJSON: the proposed mandatory "type" member for all objects. The argument for "type" is that it helps clients distinguish between geometries, features, and collections when parsing data structures. I think this is an entirely optional and avoidable implementation quirk that should not be a mandatory part of the specification.

Best practices for geospatial use of JSON make the need for "type" vanish. Querying a collection resource (all features from "cities" within a bounding box, for example) should return nothing but GeoJSON feature collections. This JSON structure in turn contains nothing but features. A request for the GeoJSON representation of a single feature resource should return nothing but a GeoJSON feature. It's as simple as that: return nothing but the proper JSON data structure.

Same story for data posted or put to resources. Collection resources should expect nothing but GeoJSON feature collections in a POST body. Single feature resources should expect nothing but GeoJSON features in a PUT body. The "type" member is completely needless, and in fact might conflict with the information that is ultimately most important: the class of web resource you're manipulating (collection or member) and the HTTP method you're using to manipulate it.

We in the geospatial business really do suffer from "standard euphoria", and need to remember there's only one first chance to get a standard right.

Update: more from Matt.


Re: Rethinking JSON for Geospatial

Author: Chris Holmes

Do we have a BOF at Foss4g? We should pick a time/place and just hash out all the final issues on GeoJSON once and for all and announce the 1.0 release of the spec at the end of the conference. I'd be happy to sprint a bit on my GeoJSON output of GeoServer to adjust to whatever we finalize on.

Re: Rethinking JSON for Geospatial

Author: Christopher Schmidt

Despite your problems with the mandatory type attribute, you didn't comment on the proposal to remove the mandatory type attribute from the spec. I'm obviously not understanding something here.

Re: Rethinking JSON for Geospatial

Author: Sean

I missed that proposal, did it go anywhere?

Re: Rethinking JSON for Geospatial

Author: Martin Davis

Seems to me this points up a fundamental issue with JSON. It intertwines the in-memory representation with the serialized representation. I agree with a comment of yours, Sean - the serialized representation should carry as much metadata and structure as possible to faithfully represent the structure of the contained information. Mushing stuff together just to avoid having to any work other than the standard Javascript parsing is not a good long-term strategy, IMO.