The Address tags section of the wiki page is quite clear that you should choose between addr:street and addr:substreet and use the latter when the delivery point is not a street. The tags-to-envelop section has this interpretation as well. Only further down in the section the addr:substreet this is contradicted with the sentence “Can also be used when a feature has two streets in it’s address”.
Anyway, looking at the actual data, the UK now has around 5k uses of addr:substreet and 63% of them have an addr:street tag as well. So the “street-or-substreet” interpretation clearly hasn’t caught on and handling addr:substreet just like addr:place is clearly not a good idea right now.
Looking in more detail at the combinations used, the vast majority of addresses has just ‘addr:street’ (92%) or no tags at all beside the housenumber (7%). Of the remaining 53k addresses we have:
addr:place (38.5%)
addr:place + addr:street (26.4%)
addr:street + addr:parentstreet (23.8%)
addr:street + addr:substreet (5.2%)
addr:place + addr:parentstreet (2.5%)
addr:substreet (1,4%)
addr:substreet + addr:parentstreet (1.4%)
as well as negligible amounts of any other possible combination including two cases with place/street/substreet/parentstreet
It’s hard to say from these numbers if addr:substreet has caught on or not but use of addr:place is still growing.
Finally, a rough count of errors on Nominatim’s suspicious street QA check tells that about 50k addr:street tags don’t have a street with the same name closeby. They are likely referring to non-street features. That’s about 1% of all addresses.
I’m afraid really don’t see the justification/need for addr:substreet.
If the numbering/naming of properties is unique within whatever addr:substreet is referring to, then you should be using either addr:street or addr:place for it instead. If there’s already an addr:street tag as well, you can change that to addr:parentstreet, and then you can change addr:substreet to either addr:street or addr:place (depending on whether it’s a street or non-street object).
I guess there could be cases where the numbering/naming is unique within some larger domain than addr:substreet. But I think that would be unusual. e.g. perhaps houses 1-5 on Main Street form a terrace that’s got a name, e.g. “West Row”. But I’m not sure how you’d write the address in that case anyway. Maybe you’d write “1, // West Row, // Main Street”. Then perhaps either addr:unit=1 + addr:housename=West Row + addr:street=Main Street or addr:housenumber=1 + addr:street=West Row + addr:parentstreet=Main Street would do.
As for some of the other combinations above, any OSM objects with addr:place + addr:street can be regarded as mistakes and flagged for review / clean-up. I think interesting question is what proportion of the uses of addr:place without addr:street are correct uses of addr:place.
addr:place is never wrong unless an object has addr:street as well, in which case it is always wrong. It should be avoided though. Favour addr:street. Use addr:place only in hamlets and villages where the streets don’t have names, only when you have to use both addr:city and an addr:suburb (of some other nearby village) as well (a so-called double-dependent locality). addr:city is always the Post Town.
I personally favour the globally approved schema (OPTIONAL (place XOR street), OPTIONAL parentstreet), and tolerate the regional thing documented on the wiki (OPTIONAL substreet, OPTIONAL street, OPTIONAL parentstreet). Use the logic in the preceding paragraph for addr:suburb and addr:city. You can use either really, and they’re both quirky mappings to the RM addressing scheme, but in different ways.
I wrote some JOSM presets for this, and I should really get around to simplifying them and getting them working in Vespucci. Break them down into different classes of address to try and hide the quirkiness of each mapping. Sigh. It’s a right ol’ mess right now.
IMO, the wiki page should be replaced with something that describes the global addr:place system and how it maps to RM addresses, but I don’t have time to rewrite it, alas.
I did have time, it was discussed (on the mailing list if memory serves me well) and this was the best we could do with the page based on the consensus at the time. It also is why we created the tags to envelope map so you can check how an OSM address (following the logic on the page) would translate to a written address on an envelope.
Of course if anyone wants to have another go at finding consensus among the community then go for it. I’m happy to share feedback based on my attempt to find consensus.
So if addr:suburb is present, is adding addr:place fine/tolerated when an address does not belong to a addr:street? (e.g. street has no name, or there is no street??)
I would say so. If there’s a “place” that’s not a “street”, and also a need for a separate addr:suburb in the address, I’d argue that this is the best way to do it.
Pointless to try and match something that is being phased out. I’ve not looked at the replacement schema for AddressBase. Thankfully it no longer matter to me.
For what it’s worth, addr:place is no longer used with addr:street in Scotland.. as of tonight. It wasn’t as much work to clean up as I thought. It’s usually fairly obvious what needs changing. It does need a human to check each address. Sometimes the place just needed changing to suburb. Sometimes the street needed changing to parentstreet, and often I also changed the place to substreet for clarity. Sometimes it was something completely different that needed doing.
I do agree with @JamesBelchamber that it’s weird that if the address is “OSM Cottage, OSM Village, OSM Post Town” then OSM Village goes in addr:place - but when the address is “42 OSM Way, OSM Village, OSM Post Town” then the same village goes in addr:suburb.
There are also some places where addr:suburbfeels wrong - like when it’s the name of an island. But I guess you just have to ignore that.
By the way, JOSM doesn’t like addr:substreet: it raises a validator warning when there is addr:housenumber and addr:substreet but not addr:street or addr:place. If you think this should not raise a warning, please back me up here, because at the moment it’s just me trying to explain to the maintainer why the tag exists.
I think it should raise a warning - not for the use of addr:substreet per se, but for the missing addr:street or addr:place. For consistency, and for the benefit of data users that don’t parse all the addr:* tags, it’s much better if addr:housenumber always represents a numbering system within the domain stored in addr:street or addr:place. Using addr:substreet breaks this. I don’t see how you can have a substreet if there’s no street anyway, or why really there’s ever a need for addr:substreet when we have both addr:street and addr:parentstreet available.
So what cases have people come across where addr:substreet seems appropriate? And can we work out a better tagging for those?
For whatever reason the current version of the addr’ in UK page currently says that you should have either an addr:street or an addr:substreet but not both.
I’ve definitely forgotten this detail between reading the page and applying it weeks or months later and just leaving the street as addr:street if there’s a sub-street grouping and not promoting it to addr:parentstreet.
To me, something like this way would make more sense as: addr:housenumber=2 addr:substreet=Andover Terrace addr:street=Andover Road[1]
than making that street a parentstreet when as far as I remember it just looks like that’s the street it’s on. It currently just has “Andover Terrace” as the street, which could work if the footpath was tagged as that but currently looks more like a square peg has been bashed into a round hole.
With the lingering examples of addr:place where e.g. addr:village would be more appropriate the addr:place + addr:parentstreet option seems ambiguous at best.
although I don’t know if this is actually used in correspondence so it might not be needed ↩︎
That wouldn’t be good, because that breaks the fact that everywhere else the addr:housenumber is a number within the addr:street object. Using addr:substreet like this makes things much more complicated for data users in general, and will break things for any that don’t parse the non-standard addr:substreet tag. (Here “2, Andover Road” is a completely different address.) Using
is much more robust and helpful to data users. If you don’t want to think of “Andover Terrace” as a street object, then you could instead use
(uddr:unit is used for numbering that’s within the addr:housename or addr:housenumber object.) Though looking at the map, you’ve got a row of houses with a common name for the row, so I’d say “Andover Terrace” qualifies quite well as a “street”.
Data consumers (geocoders) don’t work well when the thing in addr:street isn’t the name of a street (the name= of a highway= nearby). That’s what addr:place is for, so the example above should be place and parentstreet (it it’s not housename and street).
Personally I don’t see the need for addr:substreet: the only justification for it seems to be that addr:place has been misused, so if we clean up the incorrect uses of addr:place in the UK, then we can just use addr:place whenever the house number relates to something other than a street. This could be a hamlet, or it could be something smaller than a street e.g. 4 Something Cottages.
The only reason I used substreet was because it’s documented on that Wiki page, and I thought the page represented the community consensus. Specifically I have used substreet when the house number relates to something that is smaller than a street. Sometimes alongside parentstreet, sometimes just with suburb. I also thought it was clearer sometimes, instead of using place, if place had previously used on the element to mean suburb. Anyway, if we decide that we don’t need substreet, then all my uses of it can simply be replaced with place.