[gdal-dev] Time for a new GeoJSON driver?

[Sean Gillies]

Unfortunately I had to leave the conference abruptly before the BoF and
have nothing to report. Robert, was there any conclusion? New driver, same
driver?

On Tue, Aug 23, 2016 at 6:41 PM, Sean Gillies <sean at mapbox.com> wrote:

> Hi all,
>
> 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.
>
> Is there anybody on the list for whom the proposed time will not work?
>
>
> On Thu, Jul 28, 2016 at 6:12 PM, Even Rouault <even.rouault at spatialys.com>
> wrote:
>
>> > >>
>> > >> 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,
>>
>> Yes, the casual user would have trouble making the difference between
>> geo+json
>> and GeoJSON without reading carefully the doc. And RFCxxxx would be too
>> obscure. A GeoJSONv2 would be more intuitive but
>>
>> > >> 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`.
>>
>> I wouldn't use a config option/environment variable for that, but a new
>> layer
>> creation option added to the existing ones :
>>
>> <LayerCreationOptionList>
>>   <Option name="WRITE_BBOX" type="boolean" description="whether to write a
>> bbox property with the bounding box of the geometries at the feature and
>> feature collection level" default="NO" />
>>   <Option name="COORDINATE_PRECISION" type="int" description="Number of
>> decimal for coordinates" default="15" />
>>   <Option name="SIGNIFICANT_FIGURES" type="int" description="Number of
>> significant figures for floating-point values" default="17" />
>>   <Option name="NATIVE_DATA" type="string" description="FeatureCollection
>> level elements." />
>>   <Option name="NATIVE_MEDIA_TYPE" type="string" description="Format of
>> NATIVE_DATA. Must be "application/vnd.geo+json", otherwise
>> NATIVE_DATA will be ignored." />
>> </LayerCreationOptionList>
>>
>>
>> For example:
>>
>>  <Option name="FLAVOR"  type="string-select" default="TO-BE-DEFINED"
>> description="Which flavor of GeoJSON must be output">
>>     <Value>GJ2008</Value>
>>     <Value>RFCxxxx</Value>
>>  </Option>
>>
>>
>> > Personally I'd prefer RFC-by-default and no automatic reprojection --
>> with
>> > an error if the CRS isn't CRS84. Be able to opt into old style with
>> config
>> > options, which would enable outputting either fully GeoJSON2008, or
>> opting
>> > into or out-of individual RFC features (eg. fully RFC-style except
>> using an
>> > alternate CRS, or skipping antimeridian-cutting). These options should
>> > enable people to migrate systems gradually.
>>
>> Having option to turn on/off each individual RFC features seems overkill
>> to me,
>> unless there is a clear need that is expressed.
>>
>> >
>> > That would change the current behaviour and might be unacceptable,
>> > by PSC or users, then that is a good reason to create a new driver.
>> > Problem might be with the names, having two drivers means two names,
>> > and GeoJSON would still point to old driver which became de facto
>> > non-GeoJSON driver. Confusing.
>>
>> To support RFCxxxx I really think creating a new driver would be
>> technically
>> an inferior choice given the likely high percentage of common code between
>> both. On the reading side, how would you decide which driver would be
>> selected
>> ? etc...
>> A similar situation is SQLite and Spatialite that are both handled by the
>> same
>> driver, where you select the spatialite flavor with a SPATIALITE=YES
>> dataset
>> creation option.
>>
>> >
>> > > The above doesn't do good things for GDAL backwards compatibility
>> though
>> > > :)
>>
>> My feeling is that the main point of incompatibility is the crs object no
>> longer being allowed, and CRS84 being compulsory. All other points are
>> really
>> details or corner cases that wouldn't impact most use cases
>>
>> An option would be, if FLAVOR is not specified, if the SRS passed to
>> CreateLayer() is CRS84, then select RFCxxxx. Otherwise default to GJ2008.
>>
>>
>> Even
>>
>> --
>> Spatialys - Geospatial professional services
>> http://www.spatialys.com
>>
>
>
>
> --
> Sean Gillies
>



-- 
Sean Gillies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160830/c799695a/attachment.html>