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 <s...@mapbox.com
<mailto:s...@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.roua...@spatialys.com <mailto:even.roua...@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@lists.osgeo.org <mailto:gdal-dev@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Sean Gillies
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org <mailto:gdal-dev@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
--
http://schwehr.org
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
