[OSM-dev] [OSM-talk] Area tags in Overpass API

[Martin Raifer]

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 <roland.olbricht at gmx.de> 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