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

[Sean Gillies]

On Mon, Jul 25, 2016 at 4:39 PM, Even Rouault <even.rouault at spatialys.com>
wrote:

> Hi Sean,
>
> > The GeoJSON WG's draft-ietf-geojson,
> > https://datatracker.ietf.org/doc/draft-ietf-geojson/, is in the RFC
> Editor
> > queue and will be published soon. I'm considering whether adoption of the
> > updated GeoJSON (registered media type: application/geo+json) and support
> > for the older GeoJSON format (no registered media type) might be helped
> by
> > creating an entirely new driver.
> >
> > A separate driver would keep the existing driver from becoming even more
> > complicated, yes? We would also have an opportunity to remove unnecessary
> > configuration options and support for other JSON formats that aren't
> really
> > GeoJSON.
>
> I'm not completely sure we need a new driver just to support the revised
> geo+json spec. It is still mostly compatible with the original spec, right
> ?
>
> From what I can see, the differences / new specifications are :
> - SRS fixed to CRS84
> - antimeridian cutting
> - right hand rule of polygons
> - bbox and the poles&antimeridian
> - the media type
>
> Am I missing something ?
>

Two things (the full list of changes is at
https://tools.ietf.org/html/draft-ietf-geojson-04#appendix-B.1):

1. GeoJSON objects MUST NOT contain the defining members of other types.
For example, a GeoJSON Feature must not have a "features" member. I don't
see this coming up when converting from other formats, but OGR's GeoJSON
driver should filter these out of native data when writing GeoJSON.

2. Implementations SHOULD NOT extend position arrays beyond 3 elements. The
OGR driver should not by default write anything other than X, Y, Z. If it
currently writes X, Y, Z, and M, the M should be omitted.

There's one informative change in
https://tools.ietf.org/html/draft-ietf-geojson-04#appendix-B.2 that is
relevant. When GeoJSON output is CRS84 only we can certainly reduce the
default coordinate precision from 15 to 6 or 7.


>
> On the reading side, I think the existing driver requires little
> modification
> (extending "Accept: text/plain, application/json" to "Accept: text/plain,
> application/json, application/geo+json" for http:// or https:// datasource
> names) , so essentially the writing side would be affected.
>
> Regarding:
> - the right hand rule of polygons, it could be a new behaviour in all
> cases (
> the shapefile driver e.g. modifies the winding order to comply with the
> shapefile
> spec )
> - SRS fixed to CRS84, it is a matter of automatically reprojecting the
> input
> data to it if it is not CRS84, like done in the KML driver. That could be a
> default behaviour, with an option to use the deprecated crs object if
> really
> needed.
> - antimeridian cutting: can make sense as a default behaviour if the target
> SRS is CRS84. With the difficulty in doing the cutting properly ( ogr2ogr -
> wrapdateline heuristics can perhaps be improved )
> - bbox and antimerdian: if the geometry has been cut by the geojson
> driver, it
> is obvious to make the bbox conformant to the requirement. If it has been
> cut
> in a previous stage ( e.g in a geo+json->geo+json conversion), then you
> need
> to detect that the geometry has been cut ( its extent is -180 180) and then
> detect the extent of its parts
> - bbox and the poles : if the geometry is already in CRS84, then it looks
> like
> it should be just a matter of computing the bbox in the standard way from
> the
> geometry coordinates. If the geometry must be reprojected, then the issue
> is
> more the reprojection of the geometry itself :
> https://lists.osgeo.org/pipermail/gdal-dev/2016-July/044776.htm
>
> None of that really seems to call for forking a new driver.
>

Automatic reprojection to CRS84 would break existing systems that counted
on preservation of CRS. Addition of a configuration option like
OGR_GEOJSON_2008=TRUE would help, but this would still be a breaking
change, would it not?


> In the new spec, elevations are explictly ellipsoidal heights. In the old
> spec, it wasn't explicit. Although I'm not sure all elevations passed in a
> (x,y,z) triplet with x,y being in CRS84 are really ellipsoidal heights in
> practice, this is probably out of scope of the driver ( unless it would be
> fed
> with a SRS that would explictly specify the VERTCS and thus vertical datum
> transformation could potentially be done )
>
> >
> > Does anyone feel that the existing driver code *would not* be a good
> place
> > to start and that we shouldn't arrive at a new driver by copying the
> > existing GeoJSON driver and removing unneeded code?
>
> What could possibly justify a new driver to me is a driver that would
> support
> reading geojson files of arbitrary size without fully ingesting them into
> memory. That would have probably quite a big impact on the existing code
> base,
> especially since GDAL 2.1 where the driver assumes in-memory ingestion to
> be
> able to provide the update support.
>

I do not know how OGR supports in-place update of GeoJSON, but I'll take
your word on it.

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