[gdal-dev] Call for discussion on RFC 60: Improved round-tripping in OGR

[Kurt Schwehr]

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



-- 
--
http://schwehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20151014/e72ed232/attachment.html>