On 31.01.2013 14:06, Martin Koppenhoefer wrote: > 2013/1/31 Tobias Knerr <o...@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. Tobias _______________________________________________ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
