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

[Even Rouault]

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

<LayerCreationOptionList>
  <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." />
</LayerCreationOptionList>


For example:

 <Option name="FLAVOR"  type="string-select" default="TO-BE-DEFINED" 
description="Which flavor of GeoJSON must be output">
    <Value>GJ2008</Value>
    <Value>RFCxxxx</Value>
 </Option>


> 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 
? etc...
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 
creation option.

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


Even

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