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

[Even Rouault]

Sean,

We ended up cancelling the BoF.
I had a discussion with someone (Dmitry perhaps ?) and there was some concerns 
expressed by turning on RFC 7946 by default, even in the case of a source 
dataset in EPSG:4326. Particularly because of the behaviour at dateline, where 
RFC 7946 asks for geometries to be cut and coordinates to be wrapped around

One downside of having a new driver is that it creates issues for the read 
side of it. Due to the absence of versionning, how would you know if a json 
file must be handled by one driver or another ? In some cases, you could know 
(e.g. presence of a "crs" object), but generally you would need to parse the 
whole file and detect a few hints (like longitudes > 180 or <-180, unexpected 
orientation for polygons, etc). So you might end up parsing the file twice.

So I'd be more on the position to have a single driver that supports writing 
both "flavours" through a creation option. And probably default to GJ2008 to 
avoid breaking existing workflows (perhaps with some warning in release notes 
that the default might change in a later release, so people should explicitly 
specify the creation option if they depend on the precise flavour)
We could conceptually have a light-weight RFC7946 driver (or whatever we would 
call it) that would be just a wrapper around the existing driver and would set 
the creation option with the right flavour, but that would probably be a bit 
weird that this driver is never used on the read side (due to what I 
mentionned above).

One thing that is not completely obvious is how to handle edition capabilities 
(ie when the dataset is opened in open mode). When you re-write the file after 
a feature addition/update/deletion, which flavour do you choose ? Probably use 
the heuristics I mentionned before to have a best guess, and offer an open 
option with the flavour as well.

For RFC 7946, there were different opinions if I re-read the thread regarding 
if we must turn on automatic reprojection to EPSG:4326, or just error out if 
the CRS used at layer creation time is EPSG:4326.
We have already a few drivers whose underlying format is coordinates in 
lon,lat and that accept arbitrary CRS at creation time with on the fly 
reprojection. One advantage of this is that you can identify more easily 
geometries at the pole or the anti-meridian and thus write them correctly 
according to the new rules.
But anyway we would also need some heuristics in the case where you convert to 
RFC 7946 for example from a format in EPSG:4326 with geometries cut at the 
dateline. In the OGR geometry model, there's nothing that explictly tells if 
the geometry has been cut or not. So you might need to use the following 
heuristics: if a multipart geometry has longitudes both at -180 and 180 in 
different parts (ie that the same part of a geometry doesn't have points both 
at -180 and 180), then it has been cut.

Even


Le mardi 30 août 2016 16:59:12, Sean Gillies a écrit :
> 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

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com