[GeoJSON] Mailman works in mysterious ways/Consequences of the GeoJSON 1.0 axis order policy

[Allan Doyle]

Well said, Howard.

	Allan

On Apr 12, 2013, at 11:58 AM, Howard Butler <hobu.inc at gmail.com>
 wrote:

> 
> On Apr 12, 2013, at 10:11 AM, Martin Daly <Martin.Daly at cadcorp.com> wrote:
> 
>> Please see the message below, from Adrian Custer.
> 
> ... A bunch of good, correct, and accurate points by Adrian about GeoJSON's axis ordering deficiencies ...
> 
>> Unless I am mistaken you have a choice to make, which choice you follow is entirely up to those who do the work to address the ambiguity in the current standard.
> 
> The third choice, which you haven't mentioned, is to do and say nothing. We could acknowledge these issues with a simple "so what?" and be on our merry way.
> 
> GeoJSON does not exist to solve 100% of people's geographic data transport problems. GML exists to do that already. That was never GeoJSON's scope. Almost all of the argument GeoJSON's spec development has had has been caused by people wanting to increase the scope to include things like schemas, axis ordering, precise coordinate system representation, etc. If OGC has all of that space covered, why do it again?
> 
> GeoJSON absolutely is deficient as far as axis ordering is concerned, and it happily/blissfully/ignorantly carries on without regard to it quite successfully. If we made any mistake in coordinate system description for GeoJSON, it was to try to give some flexibility instead of simply allowing only two -- 4326 and 900913. As time has gone on, it's quite clear that those two would have covered the vast majority of GeoJSON's usage footprint, and everyone could have gotten to/from where they wanted to go as far as coordinate systems go via those. If we were to release a new version of the specification, my suspicion is we'd look to simplify rather than complexify this aspect to the point of possibly dropping it entirely.
> 
>> My own argument lies in a different community: first, that, absent some clear statement of the CRS restriction, the OGC cannot standardize on use of GeoJSON even for the limited set of CRS where it works, and second, that unless a general solution is provided by GeoJSON, the OGC will have to fork its own OgcJSON standard, identical to GeoJSON except for the axis order policy so that we can support the breadth of CRSs encountered in our domain.
> 
> OGC is certainly welcome to fork their own variant of OgcJSON, which I'm sure will be different and more complex than EsriJSON in some substantial and reasonable way. Why does OGC wish to standardize on GeoJSON when it has GML (or KML?) as its prescribed geometry transport format? GML has everything you need here, and GeoJSON is deficient, right? I don't get the desire to add GeoJSON as a "standardized" transport format other than to capitalize on the traction GeoJSON has gained in the market. It's gained this traction *due* to its stupidity, not in spite of it, however.
> 
> GeoJSON is successful because it sticks to its core principles. Constraint over flexibility. Web over Geo/GIS. Dumb over smart.
> 
> Others may have different opinions, and I appreciate the exposition of the issues, Adrian. I have a hard time seeing us make this aspect of the specification more complex for implementors. Most ignore CRS issues right now except for determining if it is 4326 or 900913. I'm not convinced that more complexity for completeness' sake is going to have traction.
> 
> Howard
>