I think this might be a little bit too technical for the talk-ML, so I'm posing this here:

22.03.2013, 23:38, Roland Olbricht <[email protected]> wrote:

And there is even a future driven reason to encourage feedback: In the long term, Overpass API will produce GeoJSON to allow vector rendering.
The main roadblocker for this is the distinction between linestrings
and polygons. I assume that an established list of tags that designate
areas are the best way to achieve this with long-term stable semantics.

While I think that integrating a more end-user friendly output format to Overpass is generally a good idea, integrating GeoJSON directly in the Overpass API could also be disadvantageous for a number of reasons:

Besides the mentioned "LineString/Polygon" distinction, there will be more complications: What do you intend to do with relations? One could create featureCollections for each relation, duplicating the underlying geometry or putting the relation membership status into each feature, thus duplicating the relation data itself. Depending on the use case, either of the methods would be better suited, but you can hardly implement both in the same output format. With GeoJSON, you will loose some data which would be present in the OSM data (most notably probably node-ids of way-vertices, but also master-relations, relations without members, ...). Also, you will loose some information about the relation between objects. For example, when two polygons share an edge, that edge should only be considered once for geometry generalization. Without vertice-ids it is harder to implement such a "common edge" matching. For this use-case it would be much better to have topoJSON [1] as an output format.

That said, in my opinion a solution for this would be to provide an "intermediate" data format, which is not as restrictive as GeoJSON, but also not as hard to handle as OSM-XML. And I think you already have such a format implemented in the Augmented-Diffs API [2].

With such an output-format at hand, it would be easy to create another API on top of that, that could generate the desired output for the end-user: GeoJSON, topoJSON, or whatever.

just adding my 2 cents :D
Martin / tyr_asd

[1] https://github.com/mbostock/topojson/wiki
[2] http://wiki.openstreetmap.org/wiki/Overpass_API/Augmented_Diffs#geo-sorted

_______________________________________________
dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/dev

Reply via email to