[GeoJSON] Removing CRS from GeoJSON

[Stefan Drees]

On 27.05.13 21:12, Eric Lemoine wrote:
> On Wed, May 15, 2013 at 6:41 AM, Tim Schaub <tschaub at opengeo.org> wrote:
>> So as to avoid hijacking Sean's thread, I'll start a new one here.
>>
>> I'm in favor of restricting the allowed coordinate reference systems for
>> GeoJSON objects to 1: latitude, longitude coordinates relative to an
>> ellispoidal CRS based on the WGS84 datum.
>>
>> I think the second best alternative would be to restrict to 2 CRS: CRS84 or
>> EPGS:3857.
>>
>> I don't like the "allow any CRS and let axis order follow the CRS" because I
>> think it either reduces interoperability or imposes an unreasonable burden
>> on web clients (I don't know of a good web service - or really want to
>> depend on one - that provides axis order information for arbitrary CRS URN,
>> and the table is too big to ask every client to carry around).
>>
>> I apologize for having missed earlier "discussion" [1]. I haven't dug down
>> to that epoch in my inbox yet.
>>
>> And I'm in favor of the proposed RFC to IETF [2].
>>
>> https://github.com/GeoJSONWG/draft-geojson/pull/2
>>
>> [1]
>> http://lists.geojson.org/pipermail/geojson-geojson.org/2013-April/000712.html
>> [2]
>> http://lists.geojson.org/pipermail/geojson-geojson.org/2013-April/000713.html
>
>
> So, as discussed with Tim at the FOSS4G-NA conference, we, at
> Camptocamp, use GeoJSON to transport projected data. Very common use
> case of ours: EPSG:21781 (swiss projection) data stored in PostGIS,
> exchanged between client and server through custom GeoJSON-based web
> services. GeoJSON is currently the perfect format for us.
>
> If, in the future, the GeoJSON spec restricts the allowed coordinate
> reference systems to either WGS84 only, or to WGS84 and EPSG:3857,
> then it will mean that, by using GeoJSON for EPSG:21781 data, we
> violate the GeoJSON standard. This is a problem, as, for example,
> GeoJSON parsers may assume that the data is WGS84, and transform the
> parsed data to some other projection (the display projection).
>
> My first reaction to this was: "Couldn't GeoJSON just transport
> coordinate numbers and assume absolutely nothing about the data's
> coordinate reference system?". But Tim said to me that some people
> have catalogs of GeoJSON documents, and they need to somehow tell
> their users what coordinate systems they use. I think that makes
> sense.
>
> As discussed with Tim, WSG84 could be assumed when no "crs" value is
> provided only, and, if the "crs" property is present then parsers
> should assume nothing about the coordinate system. What do you think?
>
> Very sorry for waking up a bit late on this. And thanks Tim for the
> discussion at FOSS4G-NA. ...

So what I originally proposed (a crsRef instead of the crsURN that 
intermediately landed inside the I-D candidate) seems to be a not so bad 
route to follow?

I understood from the mailing list discussions:

a) The "promise" of the flexible and "fat" crs property object has never 
been kept by GeoJSON, so let's remove the brokenness of the property but 
keep the rest of the good, accepted, and used specification parts mainly 
as they are (in content).

b) Simply removing the crs member without some replacement might also 
cause problems, as for people keeping catalogs of GeoJSON-Files in 
varying projections / reference systems this removes a notational 
possibility for this assumed use case (Well, there is doubt, if really 
people use crs to note the CRS).
If they use the crs member for that purpose, they often use the 
deprecated labels to identify the CRS and not the URNs

So, what about introducing an optional crsRef member with a value as 
string being something like "EPSG:21781" or any other used crs label out 
there in the wild (even proprietary ones, why not).

I propose a name different from crs, as the structure of the member will 
be different from the current crs member, and it thus should have a 
different name.

Or am I too much geo-"alien" to get the finer points of discussion?
That may very well be, and in that case please excuse and maybe explain 
the proposed alternate solutions or identified additional needs in more 
simple detail (like even small JSON sample snippets).

All the best,
Stefan.