<div dir="ltr">Hi all,<div><br></div><div>Let's have a quick GDAL + GeoJSON BoF here at FOSS4G this week to discuss the problem, yes? How about in the Tunnel, Wednesday, after the last talk from 6-7pm? Hopefully taking much less than an hour.</div><div><br></div><div>Is there anybody on the list for whom the proposed time will not work?</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 28, 2016 at 6:12 PM, 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="">> >><br>
> >> I'm concerned that requiring users to set an environment variable for<br>
> >> conformance will extend the period of transition from 2008 to RFC<br>
> >> GeoJSON. I honestly don't know that introducing a new format name<br>
> >> ("geo+json" instead of "GeoJSON") would be better,<br>
<br>
</span>Yes, the casual user would have trouble making the difference between geo+json<br>
and GeoJSON without reading carefully the doc. And RFCxxxx would be too<br>
obscure. A GeoJSONv2 would be more intuitive but<br>
<span class=""><br>
> >> but I think it could<br>
> >> be better: `ogr2ogr -f geo+json` appears more portable (to, i.e.,<br>
> >> Windows) than<br>
> >> `RFCxxxx_GEOJSON=TRUE ogr2ogr -f GeoJSON`.<br>
<br>
</span>I wouldn't use a config option/environment variable for that, but a new layer<br>
creation option added to the existing ones :<br>
<br>
<LayerCreationOptionList><br>
<Option name="WRITE_BBOX" type="boolean" description="whether to write a<br>
bbox property with the bounding box of the geometries at the feature and<br>
feature collection level" default="NO" /><br>
<Option name="COORDINATE_PRECISION" type="int" description="Number of<br>
decimal for coordinates" default="15" /><br>
<Option name="SIGNIFICANT_FIGURES" type="int" description="Number of<br>
significant figures for floating-point values" default="17" /><br>
<Option name="NATIVE_DATA" type="string" description="FeatureCollection<br>
level elements." /><br>
<Option name="NATIVE_MEDIA_TYPE" type="string" description="Format of<br>
NATIVE_DATA. Must be "application/vnd.geo+<wbr>json", otherwise<br>
NATIVE_DATA will be ignored." /><br>
</LayerCreationOptionList><br>
<br>
<br>
For example:<br>
<br>
<Option name="FLAVOR" type="string-select" default="TO-BE-DEFINED"<br>
description="Which flavor of GeoJSON must be output"><br>
<Value>GJ2008</Value><br>
<Value>RFCxxxx</Value><br>
</Option><br>
<span class=""><br>
<br>
> Personally I'd prefer RFC-by-default and no automatic reprojection -- with<br>
> an error if the CRS isn't CRS84. Be able to opt into old style with config<br>
</span><span class="">> options, which would enable outputting either fully GeoJSON2008, or opting<br>
> into or out-of individual RFC features (eg. fully RFC-style except using an<br>
> alternate CRS, or skipping antimeridian-cutting). These options should<br>
> enable people to migrate systems gradually.<br>
<br>
</span>Having option to turn on/off each individual RFC features seems overkill to me,<br>
unless there is a clear need that is expressed.<br>
<span class=""><br>
><br>
> That would change the current behaviour and might be unacceptable,<br>
> by PSC or users, then that is a good reason to create a new driver.<br>
> Problem might be with the names, having two drivers means two names,<br>
> and GeoJSON would still point to old driver which became de facto<br>
> non-GeoJSON driver. Confusing.<br>
<br>
</span>To support RFCxxxx I really think creating a new driver would be technically<br>
an inferior choice given the likely high percentage of common code between<br>
both. On the reading side, how would you decide which driver would be selected<br>
? etc...<br>
A similar situation is SQLite and Spatialite that are both handled by the same<br>
driver, where you select the spatialite flavor with a SPATIALITE=YES dataset<br>
creation option.<br>
<span class=""><br>
><br>
> > The above doesn't do good things for GDAL backwards compatibility though<br>
> > :)<br>
<br>
</span>My feeling is that the main point of incompatibility is the crs object no<br>
longer being allowed, and CRS84 being compulsory. All other points are really<br>
details or corner cases that wouldn't impact most use cases<br>
<br>
An option would be, if FLAVOR is not specified, if the SRS passed to<br>
CreateLayer() is CRS84, then select RFCxxxx. Otherwise default to GJ2008.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
Even<br>
<br>
--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Sean Gillies</div></div>
</div>