<div dir="ltr">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).<div>
<br></div><div style>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."</div><div style><br></div><div style>
>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.</div>
<div style><br></div><div style>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.</div><div style>
<br></div><div style>This is the reason I initially pushed for the fixed coordinate order (EPSG database be damned).</div><div style><br></div><div style>Tim</div><div style><br></div><div style><br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Wed, May 15, 2013 at 8:08 AM, Allan Doyle <span dir="ltr"><<a href="mailto:afdoyle@mit.edu" target="_blank">afdoyle@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?<br>
<br>
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.<br>
<br>
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.<br>

<br>
I'd hate to have the new GeoJSON not be backwards compatible with the current one.<br>
<br>
        Allan<br>
<br>
[1] <a href="http://lists.geojson.org/pipermail/geojson-geojson.org/2013-April/000725.html" target="_blank">http://lists.geojson.org/pipermail/geojson-geojson.org/2013-April/000725.html</a><br>
<br>
<br>
On May 15, 2013, at 9:57 AM, Howard Butler <<a href="mailto:hobu.inc@gmail.com">hobu.inc@gmail.com</a>><br>
<div class="HOEnZb"><div class="h5"> wrote:<br>
<br>
><br>
> On May 15, 2013, at 4:47 AM, Martin Daly <<a href="mailto:Martin.Daly@cadcorp.com">Martin.Daly@cadcorp.com</a>> wrote:<br>
><br>
>> 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).<br>
><br>
> Me too, except for I'd mention that it is both horizontal and vertical WGS84 datums.<br>
><br>
>> I’d be wary of adding EPSG:3857 because it is the thin end of a very fat wedge.<br>
>><br>
>> 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.<br>

><br>
> 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.<br>

><br>
>> 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.<br>

><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Howard<br>
><br>
> _______________________________________________<br>
> GeoJSON mailing list<br>
> <a href="mailto:GeoJSON@lists.geojson.org">GeoJSON@lists.geojson.org</a><br>
> <a href="http://lists.geojson.org/listinfo.cgi/geojson-geojson.org" target="_blank">http://lists.geojson.org/listinfo.cgi/geojson-geojson.org</a><br>
<br>
_______________________________________________<br>
GeoJSON mailing list<br>
<a href="mailto:GeoJSON@lists.geojson.org">GeoJSON@lists.geojson.org</a><br>
<a href="http://lists.geojson.org/listinfo.cgi/geojson-geojson.org" target="_blank">http://lists.geojson.org/listinfo.cgi/geojson-geojson.org</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Tim Schaub<br>OpenGeo <a href="http://opengeo.org/" target="_blank">http://opengeo.org/</a><br>Expert service straight from the developers.<br>
</div>