[gdal-dev] Call for discussion on RFC 60: Improved round-tripping in OGR
Even Rouault
even.rouault at spatialys.com
Wed Oct 14 10:21:22 PDT 2015
Hi Kurt,
> Just gave RFC 60 a quick look. In general, I think we absolutely need
> this. Some thoughts:
thanks for the comments (by the way, anyone reading this mailing list is
welcomed to comment not just PSC members)
>
> - 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 +/-?
Theoretically, as that adds some new code, there could be some potential
impact since we are going to always store the nativeData when reading, even if
discarding it later. Hard to quantify at that point. If that were going to be
a real problem (but anyone wanting performance shouldn't use geojson to start
with), we could have an open option in the geojson driver to request it not to
populate nativeData.
> - 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.
OK
> - Do we need to add anything to the JSON to flag which conversion method
> was used?
I don't understand what you mean here.
Even
>
> -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
--
Spatialys - Geospatial professional services
http://www.spatialys.com
More information about the gdal-dev
mailing list