<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 27, 2016 at 9:40 AM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">...</span> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Automatic reprojection to CRS84 would break existing systems that counted<br>
> on preservation of CRS. Addition of a configuration option like<br>
> OGR_GEOJSON_2008=TRUE would help, but this would still be a breaking<br>
> change, would it not?<br>
<br>
</span>Automatic reprojection by default would indeed be a change. Difficult to say how<br>
breaking it is for existing workflows. Would be happy to hear about others'<br>
opinions. Another option would be to make RFCxxxx conformance an explicit user<br>
choice.<br></blockquote><div><br></div><div>I'm concerned that requiring users to set an environment variable for conformance will extend the period of transition from 2008 to RFC GeoJSON. I honestly don't know that introducing a new format name ("geo+json" instead of "GeoJSON") would be better, but I think it could be better: `ogr2ogr -f geo+json` appears more portable (to, i.e., Windows) than `RFCxxxx_GEOJSON=TRUE ogr2ogr -f GeoJSON`.</div></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Sean Gillies</div></div>
</div></div>