Matt Amos wrote: > On Fri, Apr 3, 2009 at 7:24 AM, Stefan de Konink <ste...@konink.de> wrote: >> D Tucny wrote: >>> Then shouldn't that be two nodes? with the atm one having a layer=1 tag? >>> >>> Similar to having a bar above a restaurant above a bank at the same >>> position but on different floors... >> There are better examples probably; what should a supermarket that has a >> post agency be talked like then?
[....] > 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...) On the other side, amenity = post_box;atm is even worse, since I can not use any indexing, neither on post_box nor on atm... Technically, I think that for automated tools (pathfinder, rendering, ...) the best would be to allow amenity = post_box and amenity = atm. for the same node. But this is really as technician for possibility of usage that I am speaking now, not so much as a "mapper".... I do not thing there is a right / wrong way of doing it, but currently I think the way of having several tags with the same key offers more flexibility and could be easily used for statistics and so one... best regards. At least this is my conclusion as I am programming the automatic gathering of key / value usage statistics and relations... Best regards _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
