On 15.01.2015 17:29, Serge Wroclawski wrote: > As I examine it, it serves one very specific purpose, which is a > building with two addresses.
It can also be applied to other areas (e.g. parcels) or nodes (e.g. shop nodes). Of course, the common crux is the existence of two or more equivalent addresses. > In my experience, this setup is often (not always) associated with a > building with two entrances, each associated with an address. > > In that scenario, I'd much prefer to see two nodes, each with their > address, and each tagged as an entrance. What you prefer certainly depends on your needs. Adresses on entrances are fine for routing, maybe for visual representation too, but if you want to run a script generating a list of building sizes and addresses, you need addresses on buildings. > The other way I see these entrances used in real life is that one > business or residence within a building uses one address, while > another uses a different one. > > Here again, a POI would be more accurate and easier to parse. Yes. > This leaves us with the scenario with a building which has both > addresses associated with any entrance. Yes, that case is the main reason for the proposal. > So here we essentially a list of values. > > To that end, I don't see why we can't use the existing OSM list value > separator, the semicolon, so the address is: > > addr=val1;val2;val3 > > This is advantageous to data users because without this, they would > have to look for N arbitrary tags, as in addr, add2, add3, etc. > > What benefit does this proposal have over simply using a list separator? A list separator is fine as long as there is only one key. Unfortunately, there is no simple addr=* key. There is an addr:city=* key for the city, an addr:postcode=* key for the postcode, an addr:street=* key, and addr:housenumber=* key, and others. One complete address is therefore represented by a whole set of keys. So if you use list separators, you have: addr:city=val1;val2;val3 addr:postcode=val4;val5;val6 addr:street=val7;val8;val9 addr:housenumber=val10;val11;val12 This is possible, but error-prone, particularly with longer address parts: addr:city=New York; Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch; Ho Chi Minh City addr:postcode=14324;45345,343;5645 addr:street=Red Street; Rue Morgue; Blue Street: Green Street addr:housenumber=1;4;3;2;4 How long do you take to spot the errors? How will applications handle that data? And if one of the addresses really lacks one of the address parts (e.g. no street in case of a conscription number), you end up with an empty list element, e.g.: leading separator: addr:street=;Rue Morgue; Blue Street; Green Street or two consecutive separators: addr:street=Red Street; ; Blue Street; Green Street or a trailing separator: addr:street=Red Street; Rue Morgue; Blue Street; Green Street; With the addrN scheme, these addresses would be represented like this: addr:city=New York addr:postcode=14324 addr:street=Red Street addr:housenumber=1 addr2:city=Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch addr2:postcode=45345 addr2:street=Rue Morgue addr2:housenumber=4 addr3:city=... ... Here you do not need to count semicolons, neither do applications. You can check address for address. Which solution do you like better? -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria _______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
