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

[Howard Butler]

On Apr 12, 2013, at 11:50 AM, Volker Mische <volker.mische at gmail.com> wrote:
> Breaking backwards compatibility would only break if you use a CRS that
> is not using the easting, northing order.

Possibly, but it then puts the burden of CRS consumption and interpretation on implementors. GeoJSON is successful because the most significant burden it places on an implementor is to worry about its geometry model and how to parse it (hell, there's a lot to be said for going even simpler toward Shapefile's abdication of Multi* entirely).  GeoJSON supports casual implementation because the cognitive burden to get consuming coordinates is copy/paste'ing from the examples and fiddling with the dict/hash/map and array classes in your favorite implementation language. 

Adrian's point about GeoJSON functionally only supporting easting, northing coordinate systems is accurate, but GeoJSON wasn't designed with self-describing systems in mind (do these systems ever work beyond one level of abstraction?). Design is too strong of a word for how GeoJSON was arrived at anyway. The current spec is simply the point at which we stopped iterating proposals. It's very much open source-style software development in that sense.

Like all good open source software, it can't afford to foist arbitrary breaking changes on its implementors for theoretical gains in compatibility and featurefulness. The chance to do that was when the spec was iterating. If we break our audience of implementations with a new specification, some will be updated for sure, but many more will not be, and we've essentially forked our effort. WMS 1.3 did exactly this, and instead of people reinvesting in WMS to bring things forward, the investment instead went to tile-based systems that traded computation for storage. The thought being, "if I have to break stuff to reimplement everywhere, I might as well move to something that gives me better advantages for my actual usage." 

So what happens if we break GeoJSON now in exchange for proper CRS interpretation? People have an excuse to look to something that more better fits their usages than GeoJSON does now. Is there something that out there now that fits the bill that makes more apt technical choices for the current usage where GeoJSON might be (mis)applied? I don't know the answer to that question, but us breaking things gives people an incentive to look around. The organic interop that has sprung up around GeoJSON in spite of its shortcomings would be lost or at the very least dwindle significantly.

> I wonder how many people use custom CRS? Is it really common? So far the
> GeoJSON I got was almost always using the default WGS84.

OGR's GeoJSON driver can (kind of) consume them, but it's flaky just like the specification is in this regard. That we didn't require a "crs" member signals our intentions of the importance of it. The common usage is and was WGS84 data. 

> If changing it to using the CRS order would make it possible for the OGC
> to adapt it, I'd be for it. Though I'm sure I miss a lot of implications
> and it's really bad idea. Please enlighten me.

I think the reason why we settled on the current language was to rectify the desire to store both projected and geographic coordinates and the desire to not force interpretation of the CRS. 

We've had a couple of chances now, and I don't think there is going to be another GeoJSON version. We have no way to discriminate between versions unless we bolted some attribute on in a haphazard way. GeoJSON targets what JavaScript and JSON was in the late 00's. As we've seen, JavaScript is still evolving rapidly. IMO, some subset approach, ala asm.js or RPython in PyPy-land, is going to allow dynamic-yet-predicatable-type operations to happen in a way such that passing around bloaty string representations of doubles all over the place is going to seem silly. Then someone'll be doing something like "WKB for FastBrowserScript" or "WKB for LLVM-targeted languages," and we'll start all over again.  So it goes.

Howard