[GeoJSON] Future plans for GeoJSON

Michael Geary mg at mg.to
Sat May 18 13:10:33 PDT 2013


Sean and everyone, I meant to follow up on this earlier, sorry. I see the
discussion has moved on to simply removing the CRS, so just wanted to reply
to 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?

Actually nothing discussed here (including removing CRS from the spec
entirely) will break my maps, present or future, so no worries there. My
Python code gets GeoJSON output from PostGIS and augments it with some
extra properties like the CRS, and then my PolyGonzo code in the browser
checks the CRS. That will all keep working regardless of whether this is
official GeoJSON or my own addition - I don't depend on any other code
supporting the CRS property.

So, carry on! :-)

-Mike

On Wed, May 1, 2013 at 1: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.
>
> 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.
>
> 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?
>
>
> On Fri, Apr 26, 2013 at 11:42 AM, Michael Geary <mg at mg.to> wrote:
>
>> On Fri, Apr 26, 2013 at 9:27 AM, Howard Butler <hobu.inc at gmail.com>wrote:
>>
>>> As one of the primary forces behind the CRS stuff, I support the removal
>>> of CRS from the GeoJSON specification. Adhoc specification of the
>>> coordinate system would then be left to the implementor, and a thousand
>>> turdblossoms can bloom.
>>
>>
>> I'm one of those rare people who use the GeoJSON CRS. I built a bunch of
>> election results maps for Google over the last few years, and to speed up
>> the JavaScript code a bit I used Spherical Mercator coordinates since those
>> convert directly to pixels with a single multiplication. So I use this CRS
>> in my GeoJSON files:
>>
>>     "crs": {
>>         "type": "name",
>>         "properties": {
>>             "name": "urn:ogc:def:crs:EPSG::3857"
>>         }
>>     }
>>
>> with coordinates like these:
>>
>>     "bbox": [ 737758, 4231185, 2061653, 5957068 ]
>>
>> I suppose it wouldn't make any real difference whether the crs object is
>> in the standard or not, since I could just continue to use it in any case.
>> Maybe if it weren't in the standard I would feel free to simplify it to:
>>
>>     "crs": "urn:ogc:def:crs:EPSG::3857"
>>
>> instead of all the extra structure it has now.
>>
>> So I guess I don't have an opinion one way or the other on removing the
>> CRS from the standard, just wanted to mention that I'm using it.
>>
>> -Mike
>>
>>
>
>
> --
> Sean Gillies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20130518/4b35be1c/attachment.htm>


More information about the GeoJSON mailing list