<div dir="ltr">On Thu, Jun 23, 2016 at 10:39 AM, Jukka Rahkonen <span dir="ltr"><<a href="mailto:jukka.rahkonen@latuviitta.fi" target="_blank">jukka.rahkonen@latuviitta.fi</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
It looks that with this version the use of any other CRS than CRS:84 is denied. If there still happens to be users who prefer some other CRS for example because round-trip from the native CRS used in the database into CRS:84 and back may change the cooordinates, should they start calling such geospatial JSON with some other name than GeoJSON?<br>
<br>
Regards,<br>
<br>
-Jukka Rahkonen-</blockquote><div><br></div><div>Hi Jukka,<br><br></div><div>What to call the legacy format and the modern format, what names to use, this is without a doubt a big deal. I think we'll be in good shape with the publication of this draft, better than we've ever been.<br><br>Until now, there has never been a standard for how to ask for GeoJSON by name. Requests like "can you email me GeoJSON for European country boundaries?" or "curl <a href="https://example.com/data/countries?f=geojson" target="_blank">https://example.com/data/countries?f=geojson</a>" have been relying on folk or commonsense semantics of "GeoJSON", not any standard. Today we can be very specific in an agreed upon, standard manner and ask "can you email me application/geo+json GeoJSON for European country boundaries?" or request "curl -H "Accept: application/geo+json" <a href="https://example.com/data/countries" target="_blank">https://example.com/data/countries</a>" or in a contract write "deliverables shall use RFC NNNN GeoJSON." I'm going to work hard to make this specificity normal in the industry.<br><br></div><div>Should users who want to stay with features of the legacy format change the name they use? It will certainly help if they do. In future contracts or documentation, they should write "deliverables shall use <a href="http://geojson.org" target="_blank">geojson.org</a> 2008 GeoJSON with CRS X." Changing names in deployed software is a different problem. The good news is that GDAL's "GeoJSON" driver will read application/geo+json GeoJSON with no problems. GDAL only writes legacy 2008 GeoJSON, of course, but in practice future applications will be strongly motivated to support legacy GeoJSON that uses CRS:84.<br><br></div><div>(Aside: I'd love to see GDAL get a specific application/geo+json format driver. The existing GeoJSON format driver conflates legacy 2008 GeoJSON with other, different JSON formats.)<br><br></div><div>Web services that return legacy 2008 GeoJSON should never use "Content-type: application/geo+json" in response headers. This is plainly wrong. The proper content type to use for legacy 2008 GeoJSON was never standardized. Many providers used "application/json", which remains a good option and is distinct from "application/geo+json".<br><br></div><div>If you call for "GeoJSON" (which never unambiguously named a content type in a technical sense) without being more specific, you should expect to get either the legacy or the modern format and should expect to sort out which one it is by searching for "crs" members.<br></div><div><br></div><div>Yours,<br clear="all"></div></div><br>-- <br><div data-smartmail="gmail_signature">Sean Gillies</div>
</div></div>