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

[Volker Mische]

Hi Howard,

On 04/12/2013 09:33 PM, Howard Butler wrote:
> 
> 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. 

This is exactly my point. I don't want to break the common usage like
WGS84. What I'd like to do is making GeoJSON work for more advanced CRSs
As you said, GeoJSON can be used with not so common projections, but
it's not meant for it. Hence I would break only those cases GeoJSON
wasn't really meant for. I'd call it a theoretical breakage as it will
result in almost no practical breakage.

To conclude: Break the cases GeoJSON wasn't meant for to make it work
for such cases.

Cheers,
  Volker

PS: I've CC'ed Adrian as I'm not sure if he's on the list or not, but I
want to have him included.