[GeoJSON] Removing CRS from GeoJSON

Wed May 15 11:03:25 PDT 2013

On May 15, 2013, at 1:00 PM, Tim Schaub <tschaub at opengeo.org<mailto:tschaub at opengeo.org>>
 wrote:

Yes, the suggestion to remove the "crs" member is a backwards incompatible change (it means one and only one CRS for GeoJSON).  As far as I can tell, the suggestion to add the "crsURN" member is also backwards incompatible (there was no mention of the old "crs" member in the updated spec).

crsURN was not really discussed earlier, I don't think it would be a good thing to do.

Yes, there are projection GeoJSON files in the wild.  These won't work if we remove "crs" and add "crsURN" or if we just remove "crs."

>From the perspective of a very resource constrained web client (mobile or desktop browser), I can say that it is far less of a burden to ask the client to transform from a known CRS (GeoJSON's CRS84) to a single CRS (your target CRS) than to ask that the client determine if the GeoJSON CRS (old "crs" member or new "crsURN" member) matches your target CRS (like it or not there are many ways to specify the same CRS) and only accept those that you can deal with.

If we make it so you can drag any GeoJSON file from your desktop to your browser and have it render, we win.  If we ignore this very pitiful resource constrained client, we lose.

A big +1 for that.

This is the reason I initially pushed for the fixed coordinate order (EPSG database be damned).

Yes, I totally agree.

I mainly don't want to start going down any slippery slopes that lead away from backwards compatibility and total simplicity. (Single-point lines might be ok.)

Allan

Tim

On Wed, May 15, 2013 at 8:08 AM, Allan Doyle <afdoyle at mit.edu<mailto:afdoyle at mit.edu>> wrote:
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<mailto:hobu.inc at gmail.com>>
 wrote:

>
> On May 15, 2013, at 4:47 AM, Martin Daly <Martin.Daly at cadcorp.com<mailto: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<mailto:GeoJSON at lists.geojson.org>
> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org

_______________________________________________
GeoJSON mailing list
GeoJSON at lists.geojson.org<mailto:GeoJSON at lists.geojson.org>
http://lists.geojson.org/listinfo.cgi/geojson-geojson.org

--
Tim Schaub
OpenGeo http://opengeo.org/
Expert service straight from the developers.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20130515/5cd21511/attachment-0005.htm>