What is the OpenStreetMap convention? Do we tag addresses on buildings or on separate nodes?
Posted by lxbarth on 25 October 2013 in English (English).On the imports list I recently raised the question on whether to tag addresses on buildings ways or not. Specifically, if there is only one address for a given building polygon, should the address tags sit on the building’s ways or should the address tags sit on a separate node within the building? Obviously, if there is more than one address per building, there is no other way but mapping them as nodes separate from the building way.
Eric Fischer just ran an analysis to figure out what is actually the current convention in OpenStreetMap. Here’s the short answer: addresses are tagged on building ways where possible. By a wide margin.
Read on for the numbers.
Address tagged on building ways (left) is the more common approach in OpenStreetMap versus address tagged on a separate node (right).
The rough numbers break down like this:
- 10 million buildings carry addresses on the way.
- 3 million buildings contain one or more address nodes.
- 4 million address nodes sit within a building.
So the maximum theoretical number of buildings with a single address node is 3 million minus 1. Contrast this with 10 million buildings with the address information on the way. This still assumes one crazy building containing one million address nodes and it does not discount redundantly tagged addresses in the case of POI nodes that duplicate the address of the building they sit in.
Here are the full numbers (OSM planet, September 25 2013):
Buildings 91,917,857
Buildings with address on way 9,386,811
Buildings that contain one or more address nodes 2,960,363
Address nodes within a building 3,858,096
Address nodes that are not on or within a building 10,135,036
Addresses on a node of the building way 673,975
(An address node is defined here as a node that contains an addr:housenumber tag and is not part of a building way.)
Good or bad?
For now, I’ll personally stick to this convention as it’s established. For the same reason I also want to stick to it for the ongoing New York City building and address import.
In principle though, I question tagging addresses on building polygons. It’s a special case with no benefits while separate address nodes would work in both, the case where there are multiple addresses per building polygon and where there is only one address per building polygon.
Comment from Polyglot on 25 October 2013 at 05:53
Or an Address relation containing the building, an entrance=main node at the front door and a node where the mailbox is located? I almost forgot to add the parcel to it.
Everybody happy!
Polyglot (who would also be in favour of a node per address, but does it go inside the building outline, or as a node of the building outline where the front door is?)
Comment from Hjart on 25 October 2013 at 06:27
In Denmark (that small country in northern Europe), where all addresses are imported, addresses (as I understand it) by law do not belong to any building. They are imported as separate nodes and we prefer to keep them that way. Occasionally a foreigner comes by, draws a few buildings and in the proces includes the address in the building. We consider that an error and regularly corrects it.
Comment from Pieren on 25 October 2013 at 08:18
That’s the point. Most of the addresses in OSM are today coming from mass imports. Finally only a few people fixed the convention. And the method is finally less depending on what is the best for OSM but only what is the easiest for the import. More interresting numbers would be to see the amount of contributors adopting one way or the others.
Comment from EdLoach on 25 October 2013 at 08:34
When I first started mapping addresses there was no aerial imagery so I did each address as a separate node (in the UK this is). Once OS OpenData StreetView and later Bing imagery was available I gradually replaced these by buildings with addresses on the way, based mainly on One feature, one OSM element as having the building and the address of the building separate just felt wrong.
I occasionally use addresses on nodes still. One example being where there are two or more shops in a building with a shared entrance.
I also tend to generally map what is at ground level, so haven’t yet worried too much about where there are shops on the ground level and residences above them. There is one particular row of shops where I know this to be the case and for now I’ve only mapped the shops. To survey the properties above I’d have to go through a private gate, up a flight of stairs, then along an alley on the top of the flat shop roofs. Just a bit too private for me.
Comment from mcld on 25 October 2013 at 08:49
It’s good to quantify these things, so thanks. One point: you say “by a wide margin”, but that’s not how the numbers look to me. 10 million vs 3 million is a difference of many millions, but as a ratio it’s not actually that overwhelming. The numbers suggest to me that both “conventions” are alive and well and there isn’t one convention!
I’m comfortable with there being these different approaches. I know the motivation for your post comes from the issue of deciding how to import a few thousand new items, which is more sensitive than general mapping.
Personally I fairly often map address nodes on the edge of building ways, since there are often multiple addresses associated with one building, and the only way to map them when doing a ground survey is by mapping the addresses seen on the entrances.
Comment from Stalfur on 25 October 2013 at 09:13
The margin is probably wider. In Iceland we mark both the building way and add addr also to any shops for example within the building.
This means that the shop entry by itself can stand alone and also by looking for a particular address you see the corresponding building, not the node for the hairdresser there as that might be confusing when you know your dentist is there (but his node is missing).
Personally I understand nodes as addresses when dealing with multiple addresses in a single building complex, but for stand alone buildings a node makes no sense to me personally.
Comment from Vincent de Phily on 25 October 2013 at 10:53
Firstly, just looking at your numbers, I reach the different conclusion that most housenumbers are not tagged on the building way, since “Address nodes that are not on or within a building” is the most freqent case. One can slice and regroup the numbers in various ways, but that case still seems predominant.
The difference in interpretation probably come from your “where possible” wording. But an address node that isn’t on or inside a building doesn’t necessarily mean that the building wasn’t there and therefore impossible to tag directly. One popular convention is to put the address node on the letterbox, and that physical letterbox is often not on the building. Annoyingly, it seems hard to distinguish that case from the “no building way mapped” case.
Secondly, there’ll never be a one size fits all because, the real-world concept of a “housenumber” has various meanings, even before we try to convert it into OSM objects :
For native English speakers, watch out for the fact that other languages (such as French) don’t necessarily include the word “house” to describe the concept of a housenumber, so the linguistic bias is different.
None of these real-world meanings are wrong. In fact, they coexist, which is usually solved in OSM by using a relation. I’ve never seen a type=address relation with letterbox/entrance/property/living_space member roles (I haven’t searched), but it would make pedantic sense. It wouldn’t make practical sense however, so instead we see a single one of the meanings adopted seemingly at random, but hopefully in accordance with local mapping conventions.
Comment from FraMauro on 25 October 2013 at 15:07
I also tried to have some clarifications on housenumbers some time ago: Amenity/shop with multiple housenumbers. How to map it?.
Basically I have two problems with the issue “housenumber on building way”:
here in Italy you can find not only more than one housenumber per building, but also more than one housenumber per amenity. For example one shop can have several housenumbers, and not all the housenumbers are entrances
given 1) I find more logical to find the thag where the plate is positioned. Take also into account that here the “grouping” of the housenumbers can change. An example: first shop with housenumbers (1, 3, 5); second shop with housenumbers (7, 9). After a restructuration you could have first shop with housenumbers (1, 3); second shop with housenumbers (5, 7); third shop with housenumbers (9). Not having the nodes could make managing these changes more difficult.
Comment from paulbiv on 25 October 2013 at 21:25
When I started mapping housenumbers, I used Karlsruhe-style interpolation ways. Where I hadn’t yet drawn buildings, these would end up as nodes not in buildings.
When I had drawn buildings, it’s rather random whether the nodes for the interpolation way were inside the building or not.
Now, I’ll put addresses on nodes for entrances to flats, and addresses on ways/areas for distinct houses (which can be terraces). In the UK, that looks a logical way of doing it.
Of course, requiring relations will mean it just doesn’t happen without easy support from editors.
Comment from SimonPoole on 26 October 2013 at 10:56
The stats seem to be quite compatible with the numbers I generate now and then here http://qa.poole.ch/addresses/
While I typically tend to add the address to the building outline if there is no further information available, there is no doubt in my mind that the best solution is to add it to an entrance node on the building outline (forgetting about indoor mapping and multiple addresses in the same building for now).
Adding the address information to the building itself can and does lead to routing artifacts (being routed to the nearest street to the building and not to the nearest to the entrance) that can be avoided if the entrances are mapped and hold the address info.
Comment from Tom Chance on 28 October 2013 at 11:02
One reason I prefer to add the address to the way is that I also add the other tags - amenity, building type, etc. to the way. Adding a separate node then requires somebody using the data to step through an extra hoop to find the addresses for those amenities / buildings.
This step isn’t that hard for somebody familiar with spatial joins in some proper GIS software, but plenty of people like to just link to an object on the web site to say “this is where we’re meeting”, or download a simple extract from XAPI/Overpass.
Comment from alv on 11 November 2013 at 09:41
Mappers need to keep in mind that different countries have different addressing conventions (even without the block addresses), and forcing the other countries to the system used elsewhere just won’t work. Some can assign every entrance to one house number, others can have just one house number for an apartment complex consisting of several disjoint buildings (with buildings/staircases/entrances then identified with a “staircase ref”); or one street corner building with a single entrance can have a house number on every neighbouring street, even with a lit number on each respective wall - none of them is more important or correct than the others. For what it’s worth, here we do as described in the entry: address on the building way whenever possible, otherwise (has addresses on several streets) as nodes inside the building way.
Comment from sabas88 on 18 November 2013 at 08:23
In Italy there are also two cities (Genoa and Florence) where there’s distinction between addresses for buildings (black addresses) and for commercial activities (red addresses)!
I map on a node not to overcomplicate mapping… And I don’t like the interpolation, but that’s a personal taste :-)
Comment from dieterdreist on 18 November 2013 at 19:53
We should map what is the reality. In some jurisdictions the numbers mark an entrance, in others they are assigned to an area (usually a parcel or a building). It is not always clear where the number applies to, if in doubt, use a node, but if you know the exact area a housenumber applies to it is better to put the number on this area. Using areas has the advantage that you can see the actual extension and you can infer the number for the included elements/occupants.