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 <[email protected]> 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 <[email protected]> > 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 >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/gdal-dev >> > > > > -- > Sean Gillies > > _______________________________________________ > gdal-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- -- http://schwehr.org
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
