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

[Even Rouault]

> 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.

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 
FeatureCollection
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 
most applications.

> 
> 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 
choice.

Even

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