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

[Even Rouault]

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 ?

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.

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.

Even

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