2009/4/3 Pierre-André Jacquod <[email protected]>: >> this sort of thing already exists for banks, but is tagged as >> amenity=bank, atm=yes. you could easily adopt this for other types as >> well: shop=supermarket, atm=yes. > Ok, I see, something like: > amenity = post_box > atm = yes > >> while stefan is right (there is no technical reason why we can't >> support duplicate tag keys whilst ensuring the tags themselves are >> unique), the pragmatic approach is to recognise that most clients and >> other bits of OSM software already use some sort of unique keyed map >> to store tags. > > Ok I can understand this approach. I am currently gathering statistics > (currently limited to austria and switzerland) in order to show how key > / value are used and I have the following observation: > > As drawback, I see the following point: I have a characteristic (in this > case post_box) once as a value, the second time as a key (atm=yes). > This means I am not more able to find easily all atm, e.g, since > sometime the value will appear in the value side (if this is alone) but > could / would also appear on the key side... And I have to check that I > do not have a atm = no (you never know...)
Yes, I also see this as an error in the tagging-schema. We have way too many values for "amenity" so these collisions happen all the time. It`s not just bank+atm, it is also hotel+restaurant and many others. This way of tagging amenities simply grew without any regard for what was technically possible (most editors never properly supported multiple values for a key, thus noone was to use them as their work could be destroyed at any moment). Marcus _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
