[GeoJSON] Removing CRS from GeoJSON

[Allan Doyle]

If we remove CRS altogether, how does a GeoJSON parser notice that someone has added a CRS and now the coordinates are no longer as expected?

If we want to leave open the possibility of a CRS/SRS JSON being mixed in to GeoJSON, there has to be a way to tell GeoJSON parsers that can't handle the mixin to stop parsing.

Either we have to remove it with the understanding that it's truly gone, in which case we kill off Michael Geary's EPSG 3857 data [1]. Or we have to have something like the current section 3 that tells people what to watch out for.

I'd hate to have the new GeoJSON not be backwards compatible with the current one.

	Allan

[1] http://lists.geojson.org/pipermail/geojson-geojson.org/2013-April/000725.html


On May 15, 2013, at 9:57 AM, Howard Butler <hobu.inc at gmail.com>
 wrote:

> 
> On May 15, 2013, at 4:47 AM, Martin Daly <Martin.Daly at cadcorp.com> wrote:
> 
>> I’m happy with removing CRS altogether, and forcing “lon/lat relative to an ellipsoidal CRS based on the WGS84 datum”. That matches most usage that I’m aware of (and KML).
> 
> Me too, except for I'd mention that it is both horizontal and vertical WGS84 datums.
> 
>> I’d be wary of adding EPSG:3857 because it is the thin end of a very fat wedge.
>> 
>> Tim, I think the situation that we have at the moment is better than you describe, but not by much. We have “allow any CRS and axis order will always be lon/lat or easting/northing”. We did that to avoid the burden of carrying around axis order knowledge.
> 
> The burden wasn't simply having to discriminate axis order, that would have been quite easy. The burden was every application would have to interpret axis order *or* implicitly-defined coordinate system specific axis order.  The latter is the mistake WMS 1.3 made to its demise. When we were writing GeoJSON, WMS 1.3 was still rumbling, and it was clear this was going to be a big, backwards-breaking burden. The purists may have won the argument, but the end result was no one new was willing to come play in their sandbox anymore.
> 
>> But it still has the burden on needing to know what EPSG:27700, or whatever, means. Web clients still have to get the WKT, Proj.4 string, etc, from that id (assuming that they can work with the result). So we dodged one bullet, but not the other, arguably more complex, one.
> 
> We half-assed it, and in exchange, hardly anyone dared step into the swamp. It's a good outcome in retrospect. A future revision should not make the situation worse.
> 
> The only people who are going to complain about this change are geodesists and other coordinate nerds, but they have the GML book to take shelter with.
> 
> Howard
> 
> _______________________________________________
> GeoJSON mailing list
> GeoJSON at lists.geojson.org
> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org