Hi all,
Let's have a quick GDAL + GeoJSON BoF here at FOSS4G this week to discuss
the problem, yes? How about in the Tunnel, Wednesday, after the last talk
from 6-7pm? Hopefully taking much less than an hour.
Is there anybody on the list for whom the proposed time will not work?
On Thu, Jul 28, 2016 at 6:12 PM, Even Rouault <even.roua...@spatialys.com>
wrote:
> > >>
> > >> 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
>
--
Sean Gillies
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
