[gdal-dev] Time for a new GeoJSON driver?
Even Rouault
even.rouault at spatialys.com
Mon Jul 25 15:39:07 PDT 2016
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
More information about the gdal-dev
mailing list