[Tagging] Tunnels and bridges

Tobias Knerr osm at tobias-knerr.de
Thu Jan 31 14:02:45 GMT 2013

On 31.01.2013 14:06, Martin Koppenhoefer wrote:
> 2013/1/31 Tobias Knerr <osm at tobias-knerr.de>:
>> http://ampelmann-restaurant.de/content/images/1a162245ce191485484b155c6eae79b9.jpg
> I wouldn't call this a "bridge", it is a vault, but the "bridge" (or
> viaduct) if you wanted to map it would (IMHO) be the structure as a
> whole, not just a single segment.

I don't want to discuss that example specifically. I just wanted to
point out that a value of a key - such as building - that explicitly
permits "user defined" values and is regularly used in very creative
ways isn't reliable enough for this very specific task.

You see, mappers are using building values very loosely, almost as a
free-text field. Mappers are using layers very loosely, too, often as a
rendering hint or with very exotic interpretations.

I fear that the combined effect would turn this suggested mapping style
into fuzzy guesswork.

> in this case
> you'd probably need the relation, but the relation would be useful
> anyway, this is not necessarily an alternative to relations in all
> situations, but could make them unneccesary in many cases)).

Yes, the relation is only truly necessary in some cases, but these cases
exist. So you are essentially suggesting a third, "medium complexity"
tagging style between the simple (bridge=yes) and the complex (bridge
relation) style.

However, there is a point where adding *even more* options on how to tag
the very same thing makes documentation so much more convoluted and
creating convenient editor support for all the options so much harder
that it outweighs any usability advantages the "medium complexity"
option might have offered.

I can't stop you from following that road. But I believe that, by
following the short-term goal to create a limited tagging scheme that
can be more easily used with today's editors - instead of solving the
problem at the root by improving relation presets -, you will ultimately
make things more confusing overall and make it harder for data consumers
to support all the tagging variants in use.


More information about the Tagging mailing list