So we have 2 millions things in OSM going against OSM modeling tradition: http://taginfo.openstreetmap.org/keys/addr%3Aconscriptionnumber It's same story, two addresses for one object. First: hn-street-city Second: hn-city Scheme is different, but principle is the same, two addresses for one object via tags.
Sun, 18 Jan 2015 21:52:20 +0100 от Markus Lindholm <markus.lindh...@gmail.com>: >On 17 January 2015 at 22:16, Friedrich Volkmann < b...@volki.at > wrote: >> With the addrN schema, we need one object (a node tagged shop=* and >> addrN:*=*) for a shop. >> With the provides_feature relation we need one node for the shop, one node >> for each address, and one relation. > >And if there are two shops that both have the same address? Then your >scheme breaks down as you would end up with a database with two >distinct nodes but same address. Clearly a bad thing and against the >principle of 'One feature - one element' >http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element > >> The provides_feature relation may be fine for entrances and parking places, >> but using it for addresses adds too much unnecessary complexity to the >> database. I am not sure if the "address" role is bad, but we shouldn't use >> it in cases where we can do without that relation. > >If there is a need to explicitly associate one or more addresses with >a building I don't see any other coherent way. Shoehorning multiple >address into single object just goes against how things are modelled >in OSM > >/Markus > >_______________________________________________ >Tagging mailing list >Tagging@openstreetmap.org >https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
