[gdal-dev] Time for a new GeoJSON driver?
even.rouault at spatialys.com
Wed Jul 27 08:40:45 PDT 2016
> Two things (the full list of changes is at
> 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.
OK indeed can only happen if contained in source native data
If I read 7.1 correctly, "coordinates", "geometries" and "features" are the
forbidden members of Feature
And "coordinates", "geometries", "geometry", "properties" for
Regarding geometry forbidden members, there's nothing to do as they aren't
imported from source native data.
> 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.
It doesn't currently write the M dimension.
> 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.
1e-7 degree gives roughly 1cm precision. Probably a reasonable default for
> 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?
Automatic reprojection by default would indeed be a change. Difficult to say how
breaking it is for existing workflows. Would be happy to hear about others'
opinions. Another option would be to make RFCxxxx conformance an explicit user
Spatialys - Geospatial professional services
More information about the gdal-dev