Re: [Geojson] PR #199: CRS

[Sean Gillies <[e-mail]>]

On Tue, Apr 26, 2016 at 10:36 AM, Howard Butler <[e-mail]> wrote:

>
> > On Apr 26, 2016, at 12:59 AM, Martin Daly <[e-mail]>
> wrote:
> >
> >> As I wrote there, I don't think backwards compatibility is much of an
> issue, Allan. Support for the original (and badly designed)
> >> GeoJSON CRS object has always been poor and has been dwindling.
> Software that does support it, such as GDAL, will continue
> >> to do so for some time. Nothing really changes for the users of this
> obsolete feature (GeoJSON CRS, not the idea of CRS in general).
> >
> > You cannot possibly assert these "facts" with any certainty whatsoever.
> We don't know who or what uses the GeoJSON CRS object.
>
> Indeed we can't assert that with certainty. We do know there are a number
> folks using GeoJSON with non-WGS84 coordinate systems. When we solicited
> feedback on the topic before the IETF process, some came and said so. Does
> ditching these people in exchange for future simplicity make interop of
> GeoJSON worse in the long run? IMO, no. When the IETF spec is released, and
> the Changelog is produced, and it says "GeoJSON is WGS84-only from now on,"
> I'll be comfortable knowing it is a better spec for it, even though my
> inner Geoperson™ will shake his head indignantly.
>
>
Howard, I'd like to point out again that these people using non-WGS84
coordinate systems were not even using CRS objects.

https://github.com/geojson/draft-geojson/pull/6#issuecomment-18511869
https://github.com/geojson/draft-geojson/pull/6#issuecomment-18514807

As I see it, we're not ditching them because they were never on board to
begin with.

Consider that a GeoJSON doc originates from a server that either does
(GeoServer, say) or does not (HTTP-served flat files) reproject on demand
and that it is received by a client that either does (OpenLayers, say) or
does not (Leaflet, say) reproject CRS-identified coordinates to another
CRS. Of the four different combinations of these clients and servers, the
one that may be impacted by the change we're talking about is the
combination of flat files in non-WGS84 coordinates (lets say you've got a
worldwide dataset broken up by UTM zone) and a client that reprojects them
(to, say, Web Mercator) for display or analysis. None of the other 3
combinations depend crucially on there being a CRS identified in the
GeoJSON file.

Making GeoJSON WGS84 only doesn't delete those UTM files from the server or
stop the client from reprojecting their data in any unpredictable way. It's
pretty clear how this application can eventually break: when the client
software makes a breaking change of its own to match our GeoJSON draft
(dropping support for CRS between version X and Y) and the developers of
this application are forced to upgrade (for security reasons or end of
support for their operating system) to the new version of that client
software before they can migrate their flat files. That's how breaking
backwards compatibility breaks this application. Getting the maintainers of
client software that support the old GeoJSON CRS objects today to keep that
support as a favor for legacy data can cover backwards compatibility, can
it not?

-- 
Sean Gillies