Rethinking JSON for Geospatial
2007-09-20T16:25:53Z | Comments: 4
My issues with the specification coming together at http://geojson.org 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.
