[GeoJSON] processing model

Howard Butler hobu.inc at gmail.com
Sun May 19 13:22:28 PDT 2013


On May 19, 2013, at 2:27 PM, Erik Wilde <dret at berkeley.edu> wrote:
>> I am interested in helping to provide such a service, though maybe not
>> to operate it ;-)
> 
> but the question is: can you build such a service, that for everybody can answer the question: yes, this makes sense, or no, don't expect this to work well. if you can build such a thing, it is basically an implementation of the processing model.
> 

http://geojsonlint.com/

The processing model implicit in GeoJSON is the processing model implicit in vector many(most) geometry systems used in geographic information software(s). How are we not describing the processing model of GeoJSON with the current 1.0 edition of the document and its examples? GeoJSON aims to prescribe the serialization of geometries used in GIS software. That's the implicit process model assumed (evidenced by our ape'ing of Multi* from OGC's Simple Features [1]).

[1] http://en.wikipedia.org/wiki/Simple_Features

>>> done, but namespaces imho are simply a part of a processing model, if
>>> you want to have a well-defined extensibility model.
>> we may well decide to merge the topics at anytime, but I find it good to
>> separate the topic of Identity and scope (namespace, fence, scope, ...)
>> from processing assumptions to have a better position in what to combine
>> and what to separate in the final specification.
> 
> while these issues are associated, it may make sense to stay away from the namespaces (because there simply is anything to build on, currently). but as suggested earlier, i think an explicit processing model would be very useful, and not very hard to document.

Can you expand what you mean by an "explicit processing model"?

I won't speak for any of the other authors, but I expect there is wide agreement that our IETF submission will not include "additions" to the current 1.0 specification, and if there are any substantive changes they will be to attempt to gracefully take away the failure that is the 'crs' member. If that isn't possible, we'll probably just live with it like bad drunk-night tattoo. There's no value in disrupting the ecosystem that's evolved using GeoJSON as the substrate. Good enough is good enough. 

Howard




More information about the GeoJSON mailing list