[OSM-dev] [OSM-talk] Area tags in Overpass API
tyr.asd at gmail.com
Sun Mar 24 17:01:03 UTC 2013
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
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  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 .
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
More information about the dev