addr:terrace has very limited worldwide usage and so I thought it would be good to standardise it somewhat to address tags that actually have support, In general, addr:place for the terrace name (where there is no named street with that name nearby) and addr:parentstreet where the terrace essentially belongs to a street. Generally I would only use parent street where a street name was already tagged in addr:street
One such changeset covered terraces in Bath, where a majority of the usage had been.
However, this was reverted by @DaveF on the basis that it deleted valid addr:street tags.
I am clear that there are many cases of addresses which need two lines for the thoroughfares and so two tags are needed for this. I feel that addr:place is widely supported (in the way that addr:terrace isn’t) and is valid in this case for a non-street grouping. addr:parentstreet has more limited support compared to addr:street and addr:place but is not so necessary to give a valid address.
I gave the example of way/143082632 and way/143082632 which both appear as “1 Ragland Lane” with the existing tagging of addr:terrace and addr:street. This is clearly not correct, and so I think that addr:street=Ragland Lane is not actually valid in these case. There are more than 100 other similar duplicate addresses in the changeset.
DaveF and I clearly disagree on this, so I wanted to get some other opinions on the best way to tag these terraces.
I agree that addr:terrace has limited utility. In the UK there were only about 550 uses before you started your edits. Regardless, it would have been good to have had these plans announced on the wiki first as a matter of courtesy. Addresses in the United Kingdom - OpenStreetMap Wiki states that addr:terrace is a “tag to (possibly) avoid”, so it is by all means a deprecated tag. I would however support addr:terrace being deprecated & moved into “tags to avoid”. The associated explanation in that table highlights that addr:substreet is the preferred replacement for this tag, as it means essentially the same thing (a named grouping before a full street). For that reason, it’s not clear to me why
was decided upon as the solution. I object to these changes on the basis that addr:place is not an appropriate tag when dealing with named terraces and similar. Key:addr:place - OpenStreetMap Wiki describes that addr:place should be used in places where an address is grouped by a village or settlement name rather than a named road. I also object to addr:street being moved into addr:parentstreet, leaving numerous houses without any addr:street tag at all, for example here:
Could you provide a list of the other changesets in which you have performed these changes? These changes appear to have been made in various places across the country, but it would be good to know where.
Where do they appear as 1 Ragland Lane? If you are viewing the address using an app or service that does not parse addr:terrace, of course they would appear as identical. A tag not being supported by one or many pieces of software is not a justification to change it.
The street that these houses are on is Ragland Lane. The street that is written on envelopes is Ragland Lane. So why should this not be tagged as Ragland Lane? Changing addr:street to addr:parentstreet is unjustified and leaves these houses without a commonly understood association to the street.
I agree with DaveF’s comment that addr:street is valid in all the cases that were changed in the linked changeset, but I would support migrating all instances of addr:terrace to addr:substreet with manual review.
Re software not supporting tags, would you include the use of Nominatim in OSM returning two entries for 1 Ragland Lane? The only displayed difference is postcode.
I don’t know if Nominatim is not returning other addr tags or merely that they are not being displayed in the front end search results.
Nominatim can find houses tagged with addr:substreet & addr:street, for example “3 arlingham cottages blackhorse lane potters bar” returns only the intended building, and not the other number 3 on the same street. However, it doesn’t display the substreet as part of the address in the search preview. The exact same behaviour applies to addr:terrace and addr:street. There’s no issue with nominatim in regards to these tags, it just chooses not to display them. However, other apps/services do not support substreet or parentstreet, such as comaps (#4981 - Support addr:substreet and addr:parentstreet - comaps/comaps - Codeberg.org). The combination of addr:place and addr:parentstreet like in the above screenshot does work in nominatim, but in this case the addr:place value is displayed instead of the parentstreet. I’m not sure about the combination of addr:place and addr:street, it seems to only work for some addresses, and depends on the order of the query.
I believe it also doesn’t parse/consider those tags at all (substreet, terrace, parentstreet), so there is an issue in that it won’t find objects if you search for them with the values of those tags. So if any must be used, the address should make sense without the info from those tags, and they should only be used for things that people are less likely to need to search for.
Having addr:place and addr:street is considered an error by most tools/validators, and tools may choose to only retain one of them, though there may not be any consistency on which. If both are returned, then I don’t think there’s any consensus on which way round they should appear in an address. So in short, I think it it likely to mess things up for too many existing users to propose anything using both at the same time.
(Edited to fix erroneous double negative in the first paragraph)
It does say that it is usually for groupings by settlement, but then mentions little about other groupings, that seems to be a gap in the documentation.
The OSM website was what I was specifically referring to, but as you say, also probably most other places which display it.
Clearly there is agreement that two tags are needed for such situations, the disagreement is simply on which tags they should be. My decision uses a similar line of thought to Robert’s comment above that we should put the most important part of the address (the terrace name) in the most widely used and recognised tag and the less important part (the parent street) in the less widely used tag. This gives most data consumers the best chance of parsing a valid address for such objects.
And then later contradicts itself with
addr:place+addr:parentstreet is seen as suitable
addr:place and addr:parentstreet is a common combination (over 4000 uses). Local taginfo does not seem to be working right now, so I can’t compare this to addr:place together with addr:street
Yes the page is long because we couldn’t come to a conclusion. It also notes that if some people want to do this then they should look to get the page on addr:place updated. I don’t think that has happened (not checked).
All the info is there for people to make an informed decision with things that more people agreed with higher up the page / more prominent.
The page also sets out reasons to avoid addr:place where possible (i.e. it is an inconsistent mess).
Based on the current drafting of the wiki I continue to recommend against addr:place for terrace names.
P.s. Royal Mail have this a lot simpler with just “thoroughfare” and “dependent thoroughfare” as their “tags”. I feel the closer we stick to that, the fewer of these threads we are going to see and the fewer reverts.
@confusedbuffalo - it has been brought to my attention that you’re continuing to make large-scale changes to address tags related to addr:place and addr:street, including continuing to use addr:place in innapropriate situations, such as named retail parks or other pre-street groupings. It has been made clear in this thread that addr:place should be used with caution, and is not applicable for pre-street groupings such as terrace names or the examples given above. As an example using Node: South Fusion Ltd (8361598756) | OpenStreetMap, Hedge End Industrial Estate is clearly not a settlement to which the address belongs instead of a named road. So addr:place= is definitely wrong here. It should be simply changed to addr:substreet. All you’ve done is retained the existing incorrect addr:place= tag and moved the correct addr:street tag into the less-well supported addr:parentstreet tag (leaving the poi with no addr:street set at all), for what reason? Just to solve a validator error of addr:place and addr:street being located on the same object? As shown by taginfo (addr:place | Keys | OpenStreetMap Taginfo United Kingdom), there are over 8400 examples of addr:place and addr:street used in combination - dealing with this amount of ‘errors’ should be subject to a discussion and a careful process, not just blown away with whatever method you’ve personally decided on. It’s very frustrating to see this happening. What is the point of starting a thread to discuss your use of addr:place, if you’re simply going to ignore the ongoing discussion and continue making these damaging changes?
Additional: if addr:street + addr:place is so wrong that it warrants a mass-retagging, what’s so good about addr:parentstreet + addr:place? street and parentstreet are basically the same thing and you can have the same value in either so what’s the benefit of moving one to the other?
Respectfully disagree, it is one valid option and I appreciate that there are different opinions on the matter
The address as written on an envelope would be something like
Unit 19
Hedge End Industrial Estate
Shuart Lane
St Nicholas
CT7 0NB
(Perhaps without a line break after “Unit 19”). So whilst the industrial estate is not a settlement, it is an area to which the address belongs and so is not “definitely wrong”.
Objects should have either addr:street or addr:place (not both), I think that using the less well supported tag (either addr:parentstreet or addr:substreet) for the ‘less important’ part of the address is a better way forward, since South Fusion is more correctly “Unit 19 Hedge End Industrial Estate” than it is “Unit 19 Stuart Lane”.
To improve the address data and make it more consistent and usable
Careful process, yes, discussion, not necessarily. I prefer to get on with things than discuss in circles before doing anything. I am reviewing every group of addr:street + addr:place to determine the best set of tags to use. In general, if the street should come before the place then addr:suburb was meant and so I am moving addr:place to there. If the place should come before the street then the street is a parent to the place and so I am moving the street to addr:parentstreet. I am cross-checking the address ordering by looking for nearby place=* nodes or checking websites or FSA data (using fhrs:id where it is tagged).
The current loudest voices do not constitute a majority or a consensus. Actual data consumers recommend using addr:place for this anyway. The wiki page that was written based on previous discussions documentsaddr:place + addr:parentstreet as a valid, if less common, option. Issues with it include the misuse of addr:place, noting the fact that the number of times where it is tagged together with addr:street causes complications in its use, so if we could not have that issue then the arguments against the combination are diminished.
The changes are not damaging, since they disentangle the place and the street. If you were able to get consensus that addr:place + addr:parentstreet is wrong then it would be simple to find all 4000 elements and retag them to addr:substreet + addr:street. The existing mess of addr:place + addr:street is being improved here.
Because we can’t tell at the moment whether place is a parent or a child to the street because of its misuse, retagging either addr:place or addr:street fixes this.
I’m not sure that that’s an entirely accurate characterisation of the thread, given the small number of contributors, and when you also take into account the other recent thread at Making sense of "Addresses in the United Kingdom" wiki page . And if it is, then I’m registering my disagreement with it.
The problem with using addr:substreet is that basically no data users recognise it, so they’ll either get the addresses wrong (associating the name/number with the wrong street name) or not not regard it as a valid address at all. The problem with using both addr:street and addr:place at the same time, is (as confulsedbuffalo has already explained) that there is no defined ordering for those tags, so some data users are likely to get them the wrong way round and therefore corrupt the address. Using addr:place + addr:parentstreet has the advantage that data users should always end up with a sensible address. If they understand addr:parentstreet it should be included after addr:place. If they don’t, then at the important part of the address in addr:place will be interpreted correctly.
I spoke to Sarah (who runs nominatim) at State of the Map, and she said the preferred option from her point of view for terraces etc that are have numbers but no corresponding street with a matching name would be to use addr:place for the name of the terrace. I don’t think it’s ideal, but I think it’s the least worst option that we have at the moment.
As for changes that confusedbuffalo is making, as addr:place + addr:street together is regarded as an error, I would say that correcting that to something better is definitely ok. And given the lack of consensus, I’d say the nature of the correction is at the discretion of the editor carrying it out, as long as it’s an improvement.
My understanding is that addr:place should only be used when a poi or address does not have any street address, and therefore is only grouped by the settlement name and then the post town (if it is different). An example of this would be
The Farmers Arms
Llangyndeyrn
Kidwelly
SA17 5BN
it therefore follows, that if addr:parentstreet is tagged on the object, that address does in fact belong to a street, and therefore addr:place should not be used. I still do not understand the logic that addr:place + addr:street is so wrong, but addr:place + addr:parentstreet is valid.
The second problem arises from conflating different concepts using addr:place. Where it is intended to represent a named settlement, shoehorning in industrial estates, retail parks and terrace names completely skunks it and makes it unclear if what addr:place refers to should appear in the address before or after the street/parentstreet. The conventional usage would dictate that as addr:place refers to the settlement, it should come after the parentstreet, which means the address on the envelope would actually read
Unit 19
Shuart Lane
Hedge End Industrial Estate
St Nicholas
CT7 0NB
which would be wrong.
Agreed - but why is the approach not to change addr:place? All of the objects where you’ve retained addr:place now have addr:parentstreet but no addr:street. I thought the whole reason for having parentstreet was to be able to record the fact that a regular addr:street actually ‘belongs’ to a larger street. Having no street set but a parentstreet set makes no sense to me. It also leaves all of these pois without any addr:street tagged, when they clearly do belong to a street.
This is not a helpful approach when it comes to changing the formatting of thousands of addresses and attempting to redefine what should and should not be used in combination.
What’s that supposed to mean? This just sounds like you’re brushing off new perspectives that have been raised in this thread and the other recent thread. And if you don’t think there’s a consensus, continuing the discussion first would be the best way to establish a wider view of the community’s opinions as they stand now, before starting on making large-scale changes.
The actual post you’ve linked here doesn’t support your reasoning;
This is strictly referring to places which are located perhaps on unnamed streets and therefore have no street in their address at all - which is not the case with the industrial estate example above. It clearly has a street as part of its address, and therefore addr:place is not appropriate. addr:place should only be reserved for addresses with no street at all.
They are damaging, in the cases where addr:street has been removed and changed to addr:parentstreet, leaving addr:street blank, which breaks the commonly understood connection between the poi and the street.
alright then, I’ll rephrase it to “it has been pointed out that the wiki makes it clear that addr:place is not appropriate for for pre-street groupings such as terrace names or the examples given above.”
We shouldn’t be making tagging decisions based on what is or is not supported by certain data consumers. addr:parentstreet is equally unsupported, but you advocate for using that?
I know. I never said I agree with the use of addr:street and addr:place together.
Where is it documented or explained that parentstreet should come after place? I thought the whole point was that addr:place refers to a settlement, which would come after any street-related tags?
This would be at odds with how address tags are currently documented on the wiki, and how address tags are currently used in practice. I don’t agree that it’s the least worst option - we have already established addr:substreet and addr:parentstreet so that we can get rid of all the misuse of addr:place. Switching terrace names to addr:place would be a massive regression in how addresses are tagged. What happens if you have a named terrace on an unnamed road? You can’t use addr:place for both the terrace name and the settlement name…
Could you clarify the wording of this sentence? Because of the double negative I’m not quite sure what you mean by it. You’re saying that nominatim won’t find objects that are tagged with substreet, terrace or parentstreet? If so, I’ve shown in my previous reply that nominatim does allow searching by these tags (even the relatively rare addr:terrace). I have also opened an issue on their github to request that substreet and parenstreet strings are displayed in the search results too (display addr:substreet, addr:parentstreet in search results · Issue #4200 · osm-search/Nominatim · GitHub).
So I personally would map this situation in one of two ways. the first way has already been discussed which is using the addr:parentstreet tag.
The second way I’m sure is going to be much more controversial which is to actually rename the highway to accurately represent the names of the groups of houses on either side of it utilizing the name:left and name:right tags and naming convention. Here’s some examples where I’ve done this:
My justification for doing it this way is that I believe highway=residential does not follow the same naming rules as other highways. Many modern and historic atrial roads have actual names such as a portion of the A465 is called the Heads of the Valleys road and many A and B roads also have names usually indicating where they lead to like all the Cardiff Roads and Newport Roads, etc. But the majority of residential roads I would argue that the highway should adopt the street name of the dominant group of houses that belong to it. In situations where there are multiple street names, if one is clearly dominant over the other then addr:parentstreet should be used if there is no clear dominance like in the first example of Ragland Lane, I would argue that both names should be present on the highway.
Because it’s never used for the entity that the house name/number belongs to, it’s less critical that it’s retained in any address. If a data user is only going to retain one street-like element, it’s generally better that it retains the most specific one. This avoids addresses getting completely mangled. For example “1, Short Terrace, Long Street, My Town” is better interpreted as “1, Short Terrace, My Town” than “1, Long Street, My Town”. The latter could in fact be a completely different house.
The point of addr:place is that it’s a replacement for addr:street, where house numbers/names are scoped by an object that isn’t a street. It follows that addr:place should be the first thing that comes after the house name/number. So if a data user has taken the trouble to understand addr:parentstreet, it would need to come after addr:place in the address.
It would be more accurate to say in the UK we have started using these additional tags, which are not used by most of the rest of the world.
SInce addr:place is only used when the scope of the housenames/numbers isn’t a street this isn’t an issue. You’d use addr:place for the terrace, and then whatever addr tag you’d ordinarily use for the settlement for addresses on named streets within that settlement.
I respect that that’s your opinion, but fundamentally it runs into conflict with the core definition of addr:street, even if it is a plausible interpretation of addr:place.
The addr:street tag always refers to the street that the address is physically on, and addr:place is only used as a hierarchically street-equivalent address line for addresses on unnamed streets. That is to say, addr:place is mutually incompatible with addr:street, and should only be used if there is not a named street in the address. It’s not sufficient for it to be “an area to which the address belongs”. It has to be an area in which there is no named street. Basically, addr:place shouldn’t be used in pretty much 99% of the country.
So in your example of the industrial estate, Shuart Lane is not some nearby feature that the industrial estate is somewhat proximal to, but not physically on. No, the industrial estate is indeed physically on Shuart Lane, so that necessarily must be the addr:street. This (along with the postal town) is the core anchor of the address. The addr:* keys aren’t just arbitrary text strings that we can play with as long as the end result appears in the order you’d physically write it out. It’s not something that can float up or down the hierarchy of address lines to suit our convenience. The addr:* keys have fixed semantic meaning. You can insert extra lines where needed, but that doesn’t promote (or demote) the street from what it is. The street is the street.
In terms of hierarchy, your example is a multi-unit named site. If it were residential, we’d tag it as addr:unit with addr:housename. A suggestion to tag it as an addr:place would be seen as preposterous. Granted, this is more than just a single building, so we use addr:substreet instead. But in no sense is that little industrial estate a street-equivalent feature.
Put it this way: if you were to read out that address to someone, and ask them what the street line in the address is, what would they say? They wouldn’t say “Oh there’s no street, it’s on Hedge End Industrial Estate.” No, they’d say “It’s Shuart Lane.”
The same applies to your original question about terraces. Those terraces are unambiguously on their respective streets. They’re not parent streets to some other street-equivalent feature. The terrace is not a street-equivalent feature (which is what would be required to warrant displacing the street name to addr:parentstreet). The street is the street. The terraces are on the street. The fact that each terrace has its own numbering sequence doesn’t magically change the street into something else.
I appreciate that you’re trying to solve a difficult conundrum in a way that will be supported by data consumers. But if the data consumer were a renderer, literally nobody would countenance a sweeping change to already correct tagging just to suit the renderer. Nominatim’s failure to display complete addresses is no different. We don’t tag for the data consumer.
I think you’re missing the key point that the “street-level feature” is defined not by the idea of a named street, but by what object things are numbered within. So in that sense, a named terrace within which individual houses are numbered, can very much be thought of as a street-level object. It’s the thing that provides the scope for the house numbers.
The moment you use addr:street=* and have things numbered within a different entity, data users are going to interpret things incorrectly. Using addr:housenumber + addr:substreet + addr:street does not work for terraces, since anyone who doesn’t understand addr:substreet will think the address is addr:housenumber + addr:street, which is likely to be wrong.
If we want to introduce and formalise any additional address tags to cope with the UK addresses, we should do our best to make sure that they’re backwards compatible with the scheme that everyone else is using in the rest of the world, as many data users aren’t going to worry about customising things for one small country. So any addresses we tag should make as much sense as possible when any new tags we introduce (like substreet, terrace, parentstreet) are dropped completely from them. This means that addr:substreet is almost never a good idea to use. (While this argument may be couched as tagging for data users, it’s really about not changing the long-term meaning/interpretation of existing tags.)
In terms of named terraces and industrial estates without road names within them, which are themselves on another street, I think there are two suitable ways to tag the number + entity + street combination:
1/ addr:housenumber + addr:place + addr:parentstreet
2/ addr:unit + addr:housename + addr:street
The former has the risk of the parentstreet being dropped by data users. The latter may not be seen as appropriate depending on how flexible you want to be on the use of addr:housename.
The wiki has it documented as “where a delivery point is grouped by some feature before then being associated with a (parent) street”, this does not enforce that the ‘child’ is also a street.
Respectfully, the post and those above were precisely talking about tagging for named terraces, where Robert stated that addr:place + addr:parentstreet was a suitable tag combination to use where the numbering is not continuous within the main street, he has since reiterated that here.
In the strict method for address tags to envelopes on the wiki. Confusingly, the forgiving method seems to assume that addr:place is always a mistake for addr:suburb, which may have been a majority of issues at the time, but does not seem to be the case any more. I think it should be changed to assume that addr:place is a first-level grouping unless addr:street is also tagged, then assume that is meant as a locality element. (My experience is that this is slightly more common, but not a valid assumption in all cases, hence the necessity of cleaning up such issues).
And I respect that this is your opinion, but I have not come across any documentation, guidance or rules that says that. We have invented addr:parentstreet for things like this.
Well with this rather contrived line of questioning, you are basically forcing them to say “Shuart Street”, but if you asked them in a slightly more open-ended way where “South Fusion” was, they might say something like “it’s in Hedge End Industrial Estate, off Shuart Lane”.
I agree that the terrace is on its respective street, but therefore the houses within the terrace are in the terrace, then on the street. Obviously we need two tags if we want to encode this information, the disagreement is about which two tags.
