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

[Even Rouault]

Le mardi 13 septembre 2016 14:25:59, Sean Gillies a écrit :
> Hi Even,
> 
> On Wed, Aug 31, 2016 at 1:48 PM, Even Rouault <even.rouault at spatialys.com>
> 
> wrote:
> > 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
> 
> Could I hear more about these concerns? Are there situations where it is
> more interoperable to not cut antimeridian-crossing geometries?

Perhaps one use case would be if you region of interest is centered around the 
antimeridian, you prefer your geometries to be contiguous when displayed (and 
your viewer doesn't implement repetition of geometries that would be cut) ?
> 
> > 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.
> 
> Frankly, I think that JSON is too poorly suited to the role of database to
> bother with the above.

Database is a strong word, but the 
CreateFeature()/SetFeature()/DeleteFeature() are the operations used for 
example by QGIS when editing a dataset, and having implemented them in the 
driver now makes it possible to edit easily a GeoJSON file in QGIS.

> Despite that, I think it wouldn't be a terrible
> burden on those who want to keep RFC 7946 GeoJSON to specify this in a
> config option so that we could skip the heuristics. We could use the same
> one as suggested above, I think.

Yes

> I don't understand why we would need to know if a geometry has already been
> cut. Is antimeridian cutting not idempotent? By which I mean that cutting
> again would be a no-op if the data has already been cut.

You're right. We should have idempotence at the end. I just wanted to say that 
when you need to alter the geometry because it is crossing the antimeridian, 
then you know that the naive way of computing the bbox (taking the min and max 
of longitudes) isn't going to work. But in the case where you don't touch the 
geometry because longitudes are already in [-180,180], you still need to make 
a special case when you have min=-180 and max=180 to guess if the geometry has 
been cut.


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