[gdal-dev] Time for a new GeoJSON driver?
even.rouault at spatialys.com
Thu Jul 28 09:12:40 PDT 2016
> >> I'm concerned that requiring users to set an environment variable for
> >> conformance will extend the period of transition from 2008 to RFC
> >> GeoJSON. I honestly don't know that introducing a new format name
> >> ("geo+json" instead of "GeoJSON") would be better,
Yes, the casual user would have trouble making the difference between geo+json
and GeoJSON without reading carefully the doc. And RFCxxxx would be too
obscure. A GeoJSONv2 would be more intuitive but
> >> but I think it could
> >> be better: `ogr2ogr -f geo+json` appears more portable (to, i.e.,
> >> Windows) than
> >> `RFCxxxx_GEOJSON=TRUE ogr2ogr -f GeoJSON`.
I wouldn't use a config option/environment variable for that, but a new layer
creation option added to the existing ones :
<Option name="WRITE_BBOX" type="boolean" description="whether to write a
bbox property with the bounding box of the geometries at the feature and
feature collection level" default="NO" />
<Option name="COORDINATE_PRECISION" type="int" description="Number of
decimal for coordinates" default="15" />
<Option name="SIGNIFICANT_FIGURES" type="int" description="Number of
significant figures for floating-point values" default="17" />
<Option name="NATIVE_DATA" type="string" description="FeatureCollection
level elements." />
<Option name="NATIVE_MEDIA_TYPE" type="string" description="Format of
NATIVE_DATA. Must be "application/vnd.geo+json", otherwise
NATIVE_DATA will be ignored." />
<Option name="FLAVOR" type="string-select" default="TO-BE-DEFINED"
description="Which flavor of GeoJSON must be output">
> Personally I'd prefer RFC-by-default and no automatic reprojection -- with
> an error if the CRS isn't CRS84. Be able to opt into old style with config
> options, which would enable outputting either fully GeoJSON2008, or opting
> into or out-of individual RFC features (eg. fully RFC-style except using an
> alternate CRS, or skipping antimeridian-cutting). These options should
> enable people to migrate systems gradually.
Having option to turn on/off each individual RFC features seems overkill to me,
unless there is a clear need that is expressed.
> That would change the current behaviour and might be unacceptable,
> by PSC or users, then that is a good reason to create a new driver.
> Problem might be with the names, having two drivers means two names,
> and GeoJSON would still point to old driver which became de facto
> non-GeoJSON driver. Confusing.
To support RFCxxxx I really think creating a new driver would be technically
an inferior choice given the likely high percentage of common code between
both. On the reading side, how would you decide which driver would be selected
A similar situation is SQLite and Spatialite that are both handled by the same
driver, where you select the spatialite flavor with a SPATIALITE=YES dataset
> > The above doesn't do good things for GDAL backwards compatibility though
> > :)
My feeling is that the main point of incompatibility is the crs object no
longer being allowed, and CRS84 being compulsory. All other points are really
details or corner cases that wouldn't impact most use cases
An option would be, if FLAVOR is not specified, if the SRS passed to
CreateLayer() is CRS84, then select RFCxxxx. Otherwise default to GJ2008.
Spatialys - Geospatial professional services
More information about the gdal-dev