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 _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
