For the last few months I’ve been focussing on surveying addresses in the NG9 (UK) postcode area. This is now largely complete: there are currently about 29950 NG9 addresses in the database (or 32800 after interpreting addr:interpolation, addr:flats and so on). There are still some areas that need work, these are difficult to survey places, such as gated streets. The largest current omission is around 100 residential addresses ‘behind the wire’ within an army base.
I have found tagging addresses quite a frustrating process and I suspect I would have ‘completed’ the NG9 addresses earlier if it had been more straightforward. Adding addresses is a time-consuming process and I’ve been keen that the data I am inputting is in a format that is actually useful. I have regularly thought about whether the tagging I have used can actually be used to reconstruct the full address, and indeed I have written a script to do this, in order to help me identify the pitfalls. For a typical numbered street things are relatively simple, but for anything more complicated it quickly becomes confusing and the wiki provides little guidance.
Below are my thoughts on some of the tagging issues I’ve encountered -
The issue I have found most problematic is how to tag ‘sub-streets’. These are typically short streets or terraces that ‘belong’ to a ‘parent’ street but are numbered separately. These are not uncommon around where I live.
5 Warren Arms Place, Albert Avenue, Stapleford, Nottingham
Unit 2, Westpoint Shopping Centre, Ranson Road, Chilwell, Nottingham
There is no established way of tagging these at the moment. Some users have suggested using the addr:full tag, but I don’t think this creates useful data, and I’d prefer not to bother if that’s really the only option.
There is the possibility of putting both parts in the addr:street tag separated by a comma: addr:street=”Warren Arms Place, Albert Avenue”. I initially used this method, for want of anything better, but it feels like a hack.
More recently I have started putting both parts in separate street relations and have then added the child relation to the parent with the role ‘subsidiary’. This is non-standard, but to me seems a satisfactory solution.
Around where I live addresses officially often contain a suburb/town/village/locality name in addition to the city name. This is useful for distinguishing nearby streets with the same name. In the NG9 area several street names occur twice, and a handful three times, so this is useful extra information for telling them apart. Interfaces for inputting addresses in Potlatch and JOSM don’t provide a field for this information, so the vast majority of users don’t record it at all. Until recently the wiki didn’t identify any tag except addr:city for this purpose.
Some people argue this information should be derived from administrative and other boundary relations instead. However, unless special relations are created specifically for postal boundaries, I don’t see how this could work, because there is a often a mis-match between administrative boundaries and the localities used in addresses. For example, the NG10 postcode area is entirely in Derbyshire, but the city for postal purposes is Nottingham.
I decided to use the addr:suburb tag to record this information, which has now been documented on the wiki. This is slightly problematic, because if I tag a village, should I still use addr:suburb or something else? Also, near me all addresses in the main University of Nottingham campus contain ‘University Park’, which functions very like a ‘suburb’ name. It’s hard to decide which tag is most appropriate for this (and another local user has been considering the same question). It would be good to write clearer guidelines, so the tagging can be more consistent between different areas.
It is quite common in the UK for a single address to contain a range of numbers where units have been combined together. For example, the street address of a nearby supermarket is ‘41-57 Derby Road’. There is a potential problem here, because the wiki says that numeric ranges should implicitly be treated as containing addr:interpolation=”all”. So how do you tag it if you just want it left as it is?
My view is that numeric ranges should not be interpolated unless an addr:interpolation tag has actually been added, so I have not attempted to tag these examples in a special way, despite the potential ambiguity. I suppose an alternative would be to use addr:interpolation=none or hacks such as using the addr:housename tag instead.
I have grouped most streets together using ‘street’ relations, so that it is easier to manage address tags that apply to a whole street. I notice the similar ‘associatedStreet’ relation is actually more popular. It’s a shame useful tools such as the Postcode Finder only support the latter relation type. My decision to use ‘street’ relations was simply that it seemed a better thought out proposal when I started adding addresses (2-3 years ago).
The ‘associatedStreet’ relations use the role ‘house’ for addresses, which I’ve always disliked. It leads to misunderstandings were people add roles like ‘shop’, because it’s not clear ‘house’ means any address. Also, the ‘associatedStreet’ relation used to have the totally crazy restriction that it could only contain one way with the role ‘street’. Thankfully this has long since been changed, and was obviously ignored anyway, but avoiding having JOSM’s overzealous validator repeatedly informing me that my relations had too many street roles seemed enough reason in itself to use the alternative ‘street’ relation.
Neither ‘associatedStreet’ nor ‘street’ relations (as documented on the wiki) acknowledge that the address role can contain a relation. Why not? For example, there is a school nearby that is divided into two by a main road and it is logical to put the address in a relation combining the two parts. I obviously don’t take any notice of this restriction, but JOSM’s validator inevitably again pops-up to tell me I’m doing it ‘wrong’, which could be confusing to newer users.
Comment from Tom Chance on 5 June 2013 at 08:47
Wow, that’s some very impressive (and as you say time consuming) work!
I have come across similar problems mapping addresses in my parts of south east London,
On interpolation, I added addr:interpolation=odd where I had buildings such as a block of flats containing numbers 11, 13, 15 and 17 but not the even numbers in between. Somebody came along and removed all of those - nice of them - because apparently that’s not the done thing. But it left the addressing quite ambiguous. Can you clarify what you have done in these situations?
I get a bit stuck on flats. For example, a building with flats 1, 2 and 3 is easy enough (addr:flats=1-3), but what about a building with flats “23, 23a, 23b”?
I have never really got to grips with suburbs, though it has been discussed quite a few times. The main problem I have is that the bounds of different names are very subjective, and infamously dependent on whether you speak to a long-term resident, an aspiring incomer, an estate agent or a ward councillor! So I have just ignored the whole thing, and quietly ignore the hapless attempts of Nominatim to give context to a street’s location.
Could you also explain a bit more clearly what you did for the school, or give a link to the OSM object?
Comment from SK53 on 5 June 2013 at 10:33
This is a great piece of work: and an extremely thoughtful insight into the complexities of address mapping.
Comment from will_p on 5 June 2013 at 11:27
In reply to Tom’s comments:
Regarding using addr:interpolation on individual buildings, I think it is correct. It’s really the only way to avoid ambiguity. I must have done this hundreds of times and would be most unhappy if somebody removed them. Here’s an example: http://www.openstreetmap.org/browse/way/224033525. This usage of addr:interpolation has been documented on the wiki now (not that I think the wiki should be used as the sole source in deciding whether tagging is correct).
For addr:flats, I think it’s acceptable to use a semi-colon to separate multiple numbers, so if I were tagging the example you gave, I would use addr:flats=23;23a;23b. (Some people prefer commas instead of semi-colons.)
Regarding the school I referred to, this is the link: http://www.openstreetmap.org/browse/relation/409896. It is split in two by a trunk road but joined by a foot bridge. To tag this, I decided to draw two separate polygons for the separate parts and then combined them together using a multipolygon relation with two ‘outer’ roles. I then included the amenity=school tag and the address details inside the multipolygon relation.
I like to group all the addresses on a street together using a street relation (in this case: http://www.openstreetmap.org/browse/relation/1917127). I was making a technical point that strictly (according to the wiki) ‘address’ roles in street relations are not allowed to themselves be relations (only nodes or ways). Personally I don’t see any reason for this limitation and ignore it.
Comment from Tom Chance on 5 June 2013 at 12:51
Will, thanks for the responses. I don’t know that I’ll ever match your work ethic, though! It took me five years to complete two London borough wards, and since moving from that area I’ve been much slower in gathering addresses for my new suburb. The numerous flat conversions make data gathering and entry slow, and the many extensions and odd houses on bomb sites even makes tracing to a reasonable quality laborious and boring.
As you say, it’s fiddly, time consuming and complicated. Much less fun than the good old days when I was faced with a blank slate in Reading and got to whizz around on my bike just adding streets, post boxes and pubs!
Comment from Pgd81 on 5 June 2013 at 15:13
Great post, and great work!
For retail units within a named larger building I’ve used “addr:housename=[name of building]; addr:housenumber=[number of building]; addr:unit=[number of retail unit within building]” (i.e. using the tag “addr:unit”) but I don’t know how accepted this is.
I’ve yet to delve into residential numbering, can’t quite face the thought of it. Could you use “addr:housename, addr:unit” for sub-streets? i.e. the terrace, mews etc. is considered as a building separated into units?
Comment from will_p on 6 June 2013 at 22:02
Pgd81, a late reply to your comments:
I have sometimes used the approach you suggested for retail units. While not widely used it is one method that can be used. I have also sometimes used the addr:place tag for large retail parks, where the address doesn’t really have a street just an area.
As for using addr:housename and addr:unit for residential sub-streets, I don’t think there is anything particularly wrong with doing it that way, but I suppose I think there should be a more generic solution. This is partly because it won’t work well in all circumstances: for example if the sub-street itself contains both house names and numbers. Consider this example (the names are made-up, but it’s based on a real example):
Dairy Barn, 2 Glebe Farm Court, Church Lane
This is a courtyard called Glebe Farm Court, located off Church Lane, which containing a series of dwellings with housenames and numbers. It’s not impossible to represent this using existing tags, but it would involve using 2 or 3 tags for things they aren’t really intended for, so would be rather ugly/hackish.
Comment from Pgd81 on 12 June 2013 at 11:14
An even later reply to your reply… ;-)
Totally agree there should be a better solution. Your example, where both numbers AND names exist in the sub-street, demonstrates this. The only other possibility currently mentioned in the wiki is “addr:place” (e.g. for the sub-street), but the description seems VERY strict as to how it should be used…
A different idea: the most important thing is the name/number of the premises, together with the street that the number relates to (which itself may not always be obvious, as I’ve recently discovered). Therefore arguably your made-up example should be “addr:housename=Dairy Barn; addr:housenumber=2; addr:street=Glebe Farm Court”. The information that Glebe Farm Court is a “part” of Church Lane might then be stored elsewhere – e.g. in a tag on Church Lane, or in a relation. Thoughts?