Proposal:Multiple addresses

housenumber plates (click image for description)

corner of a house, with a housenumber on each side

Multiple adresses
Proposal status:	Obsoleted (inactive)
Proposed by:	fkv
Tagging:	`addr:1:=`
Applies to:
Definition:	extend addr:* scheme to enable multiple adresses per object
Statistics:
Rendered as:	similar to multiple address nodes
Draft started:	2012-08-11
RFC start:	2012-09-21

Summary

A house (or other object) can have multiple addresses. The only way to map these addresses in OSM is currently to assign them to multiple address nodes instead of the object itself. This is a pity because applications need to find out which address nodes belong to which buildings. Another problem is that there is no consense on where to place these address nodes. Some mappers prefer to place them inside the building, while others place them at the building's margin, possibly using entrance=* nodes.

This proposal aims to eliminate the need for separate address nodes. Another goal is to clarify what an address actually is. Additionally, a new tag for PO boxes is introduced, which has not been possible with the traditional addr:* scheme.

Meaning of addresses

As already mentioned, there is no consense on where to place address nodes. Discussions always came to dead ends, because people were discussing something that had not been properly defined. Talking of addresses, people have a lot of different things in mind. So what is an address in the first place?

According to Wikipedia, "an address is a collection of information, presented in a mostly fixed format, used for describing the location of a building, apartment, or other structure or a plot of land". Thus, the address is an attribute of the whole apartment, building or even the plot of land, not just the entrance. This proposal suggests to set addresses on those objects instead of their entrances or independant nodes. However, if an entrance is marked with a house number on-site, it's ok to set addr:housenumber on that entrance too (i.e. additionally). Similarly, you may set addr:unit on an entrance marked with a staircase number.

don't coerce applications

People who set addresses on entrances mostly do that for the looks and to enable door-to-door-routing. This proposal suggests to leave it over to the renderer where to display housenumbers. As to routing, it may be better to use another entrance to the same building, depending on where you come from. A renderer or router can easily find out all entrances to an area by examining all entrance nodes which are part of the delimiting line(s).

nested objects

If you set an address for a plot of land, that address implicitly applies to all subareas (e.g. buildings) and nodes within that area (unless overruled by tags on those objects). So you don't need to set the address on the building redundantly. Similarly, you don't need to set an address on a shop (or office etc.) node if the same address is already set on the building or plot of land. However, you may want to set the address on the shop node too, because many applications are not elaborate enough to combine the tags of the shop with the address of the surrounding object.

Tagging

If an object has only one address, you can use the simple addr=* tags as usual.

If there are 2 or more addresses, insert "1:" after "addr:" for the first address, "2:" for the second address, and so on. If at least one addr:<count>:* tag exists, the simple addr:* tags (without the count-colon part) are default values for the individual addresses.

This proposal does not limit <count> to one-digit numbers, but applications interpreting only one-digit counts will rarely go wrong, as there are probably very few real-world objects with more than 9 addresses.

Example:

Let's say that this house has 4 addresses:

Foo street 1
12345 Grand City
Elbonia
Bar Road 5
12345 Grand City
Elbonia
Baz Avenue 3
12345 Grand City
Elbonia
Qux Way 2
12345 Grand City
Elbonia

The conventional approach would be to create 5 objects:

an area with building=yes
a node with addr:country=EL + addr:city=Grand City + addr:postcode=12345 + addr:street=Foo Street + addr:housenumber=1
a node with addr:country=EL + addr:city=Grand City + addr:postcode=12345 + addr:street=Bar Road + addr:housenumber=5
a node with addr:country=EL + addr:city=Grand City + addr:postcode=12345 + addr:street=Baz Avenue + addr:housenumber=3
a node with addr:country=EL + addr:city=Grand City + addr:postcode=12345 + addr:street=Qux Way + addr:housenumber=2

...totalling 5 objects with 21 tags.

The new approach is to create just one area with:

building=yes

addr:country=EL

addr:city=Grand City

addr:postcode=12345

addr:1:street=Foo Street

addr:1:housenumber=1

addr:2:street=Bar Road

addr:2:housenumber=5

addr:3:street=Baz Avenue

addr:3:housenumber=3

addr:4:street=Qux Way

addr:4:housenumber=2

new tag for PO boxes

If a resident or office has a post office box, their mail is to be delivered to the respective post office. If you want to visit them in person, you may want to enter their postal address in your routing application and to get routed to their residence. Therefore, this proposal suggests a new tag addr:pob=*, or addr:<count>:pob=*. Let's append this to the above example:

addr:5:postcode=10000

addr:5:pob=123

house number (top) and conscription number (bottom)

conscription numbers

It has so far not been possible to tag both the old conscription number and the new housenumber on the same object. We might introduce a new key for conscription numbers, but this would break compatibility with the myriads of numbers already in the database. Furthermore it is not always clear whether a given number is a housenumber or a concription number. This proposal enables you to map housenumbers and conscription numbers independently even without a new conscription_number key.

addr:country=AT

addr:city=Kaltenleutgeben

addr:postcode=2391

addr:1:street=Wilhelms-Straße

addr:1:housenumber=4

addr:2:hamlet=Kaltenleutgeben

addr:2:housenumber=263

multilingual addresses

addr:country=AT

addr:1:city=Großwarasdorf

addr:2:city=Veliki Borištof

addr:postcode=7304

addr:street=Bachgasse

addr:housenumber=1

Note that alternate names for single address parts (such as here and in the following examples) are a feature, but not the primary goal of this proposal. If there's a J F Kennedy Street in Großwarasdorf, you better fall back to semicolon notation for the street or the city, or omit alternate spellings. It is possible to extend the addr scheme later to cover this.

common spelling variations

addr:country=DE

addr:city=Coburg

addr:postcode=96450

addr:1:street=Schloßplatz

addr:2:street=Schlossplatz

addr:housenumber=1

common or obscure abbreviations

addr:country=US

addr:city=Allenport

addr:postcode=15412

addr:1:street=John Fitzgerald Kennedy Street

addr:2:street=John F Kennedy Street

addr:3:street=J F Kennedy Street

addr:4:street=Kennedy Street

addr:housenumber=1

Rendering

It's up to renderers how to handle multiple addresses on an object.

Sample Algorithms

rendering housenumbers inside

get the nearest street by name for each address
order them by importance (primary > residential) and/or closeness (0m > 100m)
for the top priority address, determine the side of the object (building) closest to the relative street
if there's enough space, display the housenumber there
continue with (3) for the next address

rendering housenumbers and/or unit numbers on entrances

if addr:housenumber is set on the entrance, display that number
otherwise determine the address(es) of the innermost object the entrance is part of
if that object has no address defined, repeat (2) with the next innermost object
get the nearest street by name for each address with a housenumber
of those streets, take the one which is closest to the entrance
take the housenumber given in that address

Do the same for unit numbers. You may combine them with regard to local conventions, e.g. using a slash as a separator.

Sample Output

rendering housenumbers inside, and labelling entrances with their unit numbers

labelling entrances with housenumbers and unit numbers

displaying the complete addresses on mouse over

Note that applications may make it configurable for the user, e.g. via a menu like this:

Sample Code

Sample perl code to resolve the address tags on an object from a hash %tags into an array @addresses:

my %addresses;
my %defaults;
for (keys %tags) {
  if (/^addr:(?:([\d]*):)?(.+)/) {
    my ($num,$subkey) = ($1,$2);
    if ($num) {
      $addresses{$num} ||= {};
      $addresses{$num}->{$subkey} = $tags{$_};
    } else {
      $defaults{$subkey} = $tags{$_};
    }
  }
}
my @addresses;
if (%addresses) {
  @addresses = map $addresses{$_}, sort keys %addresses;
  for my $key (keys %defaults) {
    for (@addresses) {
      $_->{$key} = $defaults{$key} unless exists $_->{key};
    }
  }
} elsif (%defaults) {
  @addresses = (\%defaults);
}

Benefits

leave it over to the renderer where to display housenumbers
simplification: no address nodes, all relevant tags on the same object, no need for relations
enable routing to POIs (shops, restaurants, etc.) with alternate addresses
put an end to arguments on where to place address nodes
enable mapping of housenumbers together with conscription numbers
enable multilingual addresses

Analogy

When you like to add an alternate name, would you create extra nodes just for the names? No! You set just a couple of tags on the very same object: name, alt_name, int_name, nat_name, reg_name, loc_name, old_name, official_name, short_name, sorting_name. As if this were not enough, there's also name:en, name:ru, name:de, name:hu... Hundreds of tags, all for names, never ever questioned. This proposal effectively adds 9 infixes 1..9 to the addr:* scheme. Judge yourself.

Compatibility

Applications should be aware of separate address nodes. However, their further creation is discouraged.

In order to make existing applications evaluate at least one of the addresses completely, you can set

addr:street=Foo Street

addr:housenumber=1

redundantly in addition to

addr:country=EL

addr:city=Grand City

addr:postcode=12345

addr:1:street=Foo Street

addr:1:housenumber=1

addr:2:street=Bar Road

addr:2:housenumber=5

but beware that this makes it less comprehensible to human readers, and redundancy is always problematic due to space and at later changes.

Voting

not yet

Proposal:Multiple addresses

Contents

Summary