[GeoJSON] Removing CRS from GeoJSON

[Tim Schaub]

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

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.

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

Tim




On Wed, May 15, 2013 at 8:08 AM, Allan Doyle <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>
>  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
>
> _______________________________________________
> GeoJSON mailing list
> 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/77f8eb84/attachment-0005.htm>