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

[Sean Gillies]

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? I know of
software (geojson.io, for example) that doesn't constrain longitude to
earthly values when converting coordinates to Web Mercator, but because
this behavior isn't actually specified any interoperability here seems to
be coincidental at best.


>
> 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.
>

Right. Also ordering varies in JSON files, so the "crs" object may very
well be at the tail end of a large document.


>
> 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).
>

This seems reasonable.


>
> 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. 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.


> 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.
>

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.

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