Best practices concerning addresses

Hi everyone,

I recently started completing addresses around my home. The thing is I saw people around mapped addresses in different ways.

First way : a simple node inside or near the building with addr:city, addr:housenumber, addr:postcode, addr:street tags

Second way : tagging the building way with above tags

Third way : a street or associatedStreet relation with each address having a house or address role in the relation

I understand the relation can be a way to factorize some of the addr:* tags. However, I’d like to know what are the best practices in this particular case. The documentation I read in the wiki didn’t answer all my interrogations which are :

  • Do route planners implement all above ways ?

  • Is there a preferable way to map addresses between first and second way cited above ?

Hi biologeek,

if a unique address belongs to the whole building use second way.
If there are multiple addresses or points of interests in the building use second method.
I for myself wouldn’t use associated street.

Edit: typo

Ok thanks @R0bst3r,

as I understand the simpler the better. Right ?

Right. One aim should be keep it simple.

In my area, apartment buildings commonly have multiple entrances that have their own street addresses. In such cases I put a point on the building area where each entrance is and tag each point with the individual street addresses. For houses, in my area each house lot is given a street address and IMO it would be appropriate to tag either the building (maybe at its entrance; generally that’s where, for example, mail is delivered) or to add a point (should no building exist) within the house lot and tag the point with the address.

Biologic, I also really want to start adding some addresses to the map data. Missing streets were frustrating in Google Maps, now missing addresses are sometimes a pain here. Was there something you followed that seemed to be a good reference for editing here or do you have a preferred workflow/process you follow? Thanks!

I fall back to “one object in OSM for one thing in the real world” when making decisions. Two fall outs from this: First, only one occurrence of the address should be mapped. Second, if there is already a single object that is mapped, put the address on the object.

So if there is a one to one relationship between a building and an address, I put the address information on the building.

If there are multiple buildings at an address, I create a landuse polygon around them, tag it appropriately for landuse type, then put the address on the land use polygon.

If there are multiple addresses within one building, I use nodes for each address and place them as close as i can to where they are in the building. If possible, the nodes could be on the building polygon and also be tagged as being entries.

If there is an address for a vacant piece of land (which happens in my area) then I will use a node with just the address information.

@n76: No addresses are not geographical objects, there is no reason why several geographical objects can have the same address, or that an address has no geographical associations at all, or ones which are rather broad (UK PO Boxes). We do not impose such conditions for name, operator etc, so there is no reason to do this for addresses.

The only way to have a rule that there can only be one address element is if we treated addresses as first-class objects. The Danish address authorities (notably Morten Lind) did this some time ago and find many advantages of such an approach, and I’ve found the same approach valuable for Insurance applications. However OSM has no method for so-treating non-geographical entities.