[GeoJSON] Future plans for GeoJSON

[Howard Butler]

On May 1, 2013, at 3:56 PM, Sean Gillies <sean.gillies at gmail.com> wrote:

> Howard, I can't let you take all the blame for GeoJSON's crs. A lot of that is my doing. And I think you're right that projection in the browser (like http://bl.ocks.org/mbostock/4498292 or http://bl.ocks.org/mbostock/4319903) changes the game entirely. All projecting geographic servers aren't as necessary as they used to be and long/lat ("urn:ogc:def:crs:OGC::CRS84") is increasingly sufficient.

Browsers probably won't ever do datum transformations, however, because they require a big chunk of additional data to pull off. There'll still be a modicum of desire for CRS description as part of GeoJSON's (or any geometry transport's) payload.

> Mike, I'm in favor of a single indentifier string for crs as you have above for cases where long/lat just won't do. And I think that use of RFC 5165 URNs like "urn:ogc:def:crs:EPSG::3857" make the most sense for a GeoJSON I-D. Perhaps a future CRSJSON could address cases not covered by OGC or EPSG.

I agree. IMO it's better to acknowledge that the spec is/should leak rather than to pretend it doesn't ever do so. In practice, GeoJSON's CRS stuff leaks terribly. Let's acknowledge it and move on. When all the hipsters get to revolutionizing geodesy, maybe they'll have something to say on this :)

> Other than Mike's election maps, what would break if we made crs an optional string (defaulting to "urn:ogc:def:crs:OGC::CRS84") instead of a JSON object?

I suspect we'd break a lot of parsers if we did that. I expect it would still need to be a JSON object at the very least, but we could tighten up the language to say something about really only working for 4326 or 3857 data, and anything beyond that, user's are left to meander the wilderness themselves.

Howard