[Tagging] Feature Proposal - RFC - addrN:*

[Friedrich Volkmann]

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