[gdal-dev] Call for discussion on RFC 60: Improved round-tripping in OGR
Daniel Morissette
dmorissette at mapgears.com
Fri Oct 16 08:45:56 PDT 2015
Just a quick note to say that I reviewed the RFC and like the idea.
I can see this being used someday by the MapInfo TAB/MIF drivers to
carry the native MapInfo styling info, as well as geometry in some cases
(rectangle, roundedrect, text object, etc.) to maintain them between TAB
and MIF files as this conversion can be lossy at the moment.
I also saw a suggestion that it should be possible to disable loading
the native data when we open a layer and I think that's important if we
intend to use this for more than just GeoJSON. For instance, when
loading layers in an application (QGIS, MapServer, etc.) that ignores
the native data, then it should be possible to have this overhead disabled.
We definitely need a generic option for enabling/disabling this and not
a driver-specific option. Perhaps the native data should be disabled by
default for all drivers, and be explicitly turned on by ogr2ogr and by
apps that know how to use the native info?
No other comments on my part.
Daniel
On 2015-10-14 1:07 PM, Kurt Schwehr wrote:
> Just gave RFC 60 a quick look. In general, I think we absolutely need
> this. Some thoughts:
>
> - There are users who need the old behavior. We need an easy way to get
> that. I think the default should be the more functional RFC 60 way. I
> see the -noNativeData flag, so I think this is well covered.
> - What is the likely performance impact +/-?
> - It would be nice to base a could use cases described in the RFC so we
> are not totally counting on the links. They don't have to be super
> detailed.
> - Do we need to add anything to the JSON to flag which conversion method
> was used?
>
> -kurt
>
> On Fri, Sep 25, 2015 at 1:23 PM, Sean Gillies <sean at mapbox.com
> <mailto:sean at mapbox.com>> wrote:
>
> Dear all,
>
> This feature is a boost for GeoJSON users who are extending the
> format and users of those extensions. JSON is a naturally extensible
> format but the GeoJSON OGR driver stifles development of extensions
> by passing only the fully standardized GeoJSON items.
>
> Let's say I want to use ogr2ogr to spatially filter some GeoJSON
> coming from the OSM Overpass API [1] or the Mapbox Geocoding API
> [2]. Here's what the response of the latter looks like, abbreviated:
>
> $ curl
> https://api.mapbox.com/v4/geocode/mapbox.places/1600+pennsylvania+ave+nw.json?access_token=$MAPBOX_ACCESS_TOKEN
> | python -mjson.tool
> {
> "attribution": "NOTICE: \u00a9 2015 Mapbox and its suppliers.
> All rights reserved. Use of this data is subject to the Mapbox Terms
> of Service (https://www.mapbox.com/about/maps/). This response and
> the information it contains may not be retained.",
> "features": [
> {
> "address": "1600",
> "bbox": [
> -77.05781199999998,
> 38.89252299999999,
> -77.01844799999999,
> 38.905058999999994
> ],
> "center": [
> -77.034389,
> 38.897693
> ],
> "context": [
> {
> "id": "place.57972",
> "text": "Washington"
> },
> {
> "id": "postcode.858369517",
> "text": "20004"
> },
> {
> "id": "region.1190806886",
> "text": "District of Columbia"
> },
> {
> "id": "country.4150104525",
> "text": "United States"
> }
> ],
> "geometry": {
> "coordinates": [
> -77.034389,
> 38.897693
> ],
> "type": "Point"
> },
> "id": "address.39053333360279",
> "place_name": "1600 Pennsylvania Ave NW, Washington,
> 20004, District of Columbia, United States",
> "properties": {},
> "relevance": 0.99,
> "text": "Pennsylvania Ave NW",
> "type": "Feature"
> },
> ...
> ],
> "query": [
> "1600",
> "pennsylvania",
> "ave",
> "nw"
> ],
> "type": "FeatureCollection"
> }
>
> The Features and FeatureCollection have extension items expressing
> rights, the original query, and more.
>
> When I pipe this through ogr2ogr to spatially filter, here are the
> results:
>
> $ curl
> https://api.mapbox.com/v4/geocode/mapbox.places/1600+pennsylvania+ave+nw.json?access_token=$MAPBOX_ACCESS_TOKEN
> | ogr2ogr -clipsrc -100 30 -70 60 -f GeoJSON /vsistdout/ /vsistdin/
> {
> "type": "FeatureCollection",
> "crs": { "type": "name", "properties": { "name":
> "urn:ogc:def:crs:OGC:1.3:CRS84" } },
> "features": [
> { "type": "Feature", "properties": { }, "geometry": { "type":
> "Point", "coordinates": [ -77.034389, 38.897693 ] } },
> { "type": "Feature", "properties": { }, "geometry": { "type":
> "Point", "coordinates": [ -76.634388, 39.30307 ] } },
> { "type": "Feature", "properties": { }, "geometry": { "type":
> "Point", "coordinates": [ -80.272062, 40.687045 ] } },
> { "type": "Feature", "properties": { }, "geometry": { "type":
> "Point", "coordinates": [ -95.54508, 34.841595 ] } }
> ]
> }
>
> The extensions are lost. This means that ogr2ogr can't be used in
> pipelines that process extended GeoJSON.
>
> If you want your GeoJSON to pass through OGR in high fidelity, you
> have to put everything in the Feature.properties object no matter
> whether that's the best place for it or not. In practice, the
> Feature.properties object becomes a grey goo of feature attributes,
> styling properties, and you name it.
>
> The implementation of RFC 60 would pass through GeoJSON extensions
> in full hi-fi. OGR will no longer be an impediment to extension
> developers.
>
> [1] http://wiki.openstreetmap.org/wiki/Overpass_turbo/GeoJSON
> [2] https://github.com/mapbox/carmen/blob/master/carmen-geojson.md
>
> Yours,
>
>
> On Wed, Sep 23, 2015 at 9:29 AM, Even Rouault
> <even.rouault at spatialys.com <mailto:even.rouault at spatialys.com>> wrote:
>
> Hi,
>
> This is a call for discussion on "RFC 60: Improved
> round-tripping in OGR".
>
> https://trac.osgeo.org/gdal/wiki/rfc60_improved_roundtripping_in_ogr
>
> This RFC defines how to improve better round-tripping in
> conversion of vector
> formats, in particular for GeoJSON extensions.
>
> Best regards,
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
>
> --
> Sean Gillies
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
>
> --
> --
> http://schwehr.org
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
--
Daniel Morissette
http://www.mapgears.com/
T: +1 418-696-5056 #201
http://evouala.com/ - Location Intelligence Made Easy
More information about the gdal-dev
mailing list