I don’t know how legitimate it is, but this node is claiming:
addr:unit=3
addr:substreet=The Exchange
addr:street=Brewery Court
addr:parentstreet=Cricklade Street
addr:city=Cirencester
addr:postcode=GL7 1JL
The surroundings make that seem vaguely plausible.
The other examples I can see of addr:substreet, addr:street and addr:parentstreet all on the same element seem like they’re double tagged.
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:
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.
This is more consistent with the wiki for the addr:street key. It’s still the relevant street for that address.
If you really can’t have addr:substreet and addr:street together then the tag should really be addr:subparentstreet.
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 don’t really understand the obsession with being perfectly compatible with PAF and/or AddressBase, we aren’t recreating those databases. It’s OK.
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:suburb feels 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.
Hmm. I think I used to think so, but I don’t think that any addr:suburb (or hamlet, village) is necessary. Picking a local example, 42 Littleworth, Oxford, [OX33 1TR] (I checked on Postcode Finder, and I hope that shows everything). It’s a “street has no name” example.[1]
For Royal Mail PAF, it’s fine to have no Thoroughfare elements if the Locality unambiguously identifies where the Premise is, whereas in OSM I think there should always be an addr:place or an addr:street (which are supposed to have an identical “weight”) if there are any of addr:housename or addr:housenumber present (both are clearly Premise details). I’m not happy seeing addr:housenumber and/or addr:housename without a corresponding addr:street or addr:place in the OSM schema, so I did it this way:
| OSM key | Value (both) | PAF Field Name | PAF Field Category |
|---|---|---|---|
addr:housenumber |
42 |
Building Number |
Premise |
| ↓ | n/a [2] | Thoroughfare |
Thoroughfare |
| ↓ | n/a [3] | Street |
Thoroughfare |
addr:place |
Littleworth |
Dependent Locality |
Locality |
addr:suburb |
Wheatley |
↑ | |
addr:city |
Oxford |
Post Town |
Locality |
addr:postcode |
OX33 1TR[5] |
Postcode |
Locality |
The table lines up PAF elements with OSM tags, but this isn’t a mapping we can use generally. It’s just an address-specific alignment in the order you write things on an envelope. No general mappings are possible.
This address, if I was to remove “Wheatley” and add a proper Postcode, would be a minimal example that’d work out in both schemas. I do think that addr:suburb has a use outside city boundaries, usually for villages or towns, however this example doesn’t need the addr:suburb level, or anything like it, since there’s no other Littleworths under this Post Town,
But note that addr:place has “floated” ↓ from a Thoroughfare-ish element to a Locality-ish element, if you look at it via a RM lens. That’s weird, but that’s absolutely fine. You don’t ever use addr:street with addr:place, and as a project we’re not about mapping our address elements 1:1 to the database schema of some local incumbent addressing authority anywhere in the world.
For the UK, you’d have to find a real double-dependent locality where the streets have no name, AND where you need an addr:place to unambiguously identify premises below the double-dip level for the alignment above to get bent out of shape. Even then, I think you can get away with a new alignment that replaces addr:suburb with addr:hamlet and addr:village, freeing up addr:place.
We do need a strict ordering of OSM tags for UK use, and as many fixed mappings as we can to make this work. I think we have that, and we do at least have the house number/name and the postcode/post town ends as fixed points.
There is a Littleworth Road leading to it from Wheatley, but the street through this hamlet has no name itself. Locals give addresses as “<Number> [no comma] Littleworth, Oxford”. Some competitor maps write “Littleworth” on the road, but it’s not signposted as such on the ground (yet). The lack of a street name is bourne out by historical records too. ↩︎
In there PAF schema, if there’s no Street, there can’t be a Thoroughfare ↩︎
As far as Royal Mail are concerned, the Locality fields identify it fully ↩︎
This is probably not necessary for either schema! I might have thought it might be a double-dependent locality at the time, but it isn’t. ↩︎
I can’t use this value in OSM because this line comes from Address Finder, for the purposes of discussion. But it would go in addr:postcode if I could use it. ↩︎