<div dir="ltr">


        
        <span></span>Hi all,<br><br>A few more responses.<br><br><b>Rick:</b><br>On the topic of addr:flats and addr:unit I also feel it is silly to have two choices here. I think if you look at Simon’s messages to this thread then you will see that there is similar excess of tags in other places too. The only reason I can think of for this is that the tags use words that we all apply our own personal and subjective interpretation to. In this case mappers probably see “unit” more as an industrial sub part of a building, whilst “flat” is seen as a domestic sub part of a building. Both cases are just trying to say “sub part” but unfortunately we now have two tags. Let's just hope nobody introduces addr:apartment as it seems to be popular to call flats apartments these days!<br><br>It’s exactly the same for addr:hamlet, addr:village and addr:town. That is, people read addr:city, applied their view of what a “city” is and decided to create other tags. Same for addr:suburb and hence addr:locality gets invented and used.<br><br>The OSM UK project will use addr:unit for single addresses when a sub part is needed. The best advice I can give is to help clean up incorrect addr:flats tags and if any addr:unit tags are used for multiple addresses, then split them out into individual addressees.<br><br>If somebody wants to raise a proposal to make addr:flats deprecated in the UK then please proceed. You have my vote (just that I am not going to raise that myself as already in deeper than I had planned).<br><br><b>Robert:</b><br>I agree that if any of the child tags (addr:substreet, addr:terrace, addr:street) are used, then the parent element should be in addr:street. As such I agree that it is an “error for an object to have more than one of addr:street, addr:place, addr:substreet and addr:terrace”. I drafted the wiki page to cope with cases where people break this rule as I suspect that will happen regardless of whether that text is included or not.<br><br>On the question “I also wonder whether we need to include addr:terrace as an option, now we have addr:substreet”: I agree. I personally won’t be using addr:terrace and the OSM UK editing tool won’t either because asking people to pick a “feature specific” child tag is overly complex for the tool we are making. Same comment I made above to Rick: If someone wants to propose deprecating this addr:terrace tag in the UK then please feel free to.<br><br>As for addr:locality I think you can guess my response. It is one of these cases where I feel mappers have applied their perception of what a “suburb” is and therefore created a new tag. addr:suburb is sufficient as a general “sub area (i.e. locality) of a settlement regardless of the size of the settlement” type tag. Why do you feel you need something different to addr:suburb? <br><br>Finally, regarding the position of addr:place before or after addr:parentstreet, then I suspect based on what Sarah said about most people using addr:place when they should have used addr:suburb, that after parent street is best. Either way, addr:place is a big mess in the UK and hence the call on the wiki page to clean it up. Only by doing that will data consumers get a better result. For your specific example of an industrial estate off a main street, then I’d use addr:substreet + addr:parentstreet. Implying place is a “child” feature was widely disliked when the “parent” feature was addr:street. I suspect that dislike continues with addr:parentstreet too.<br><br><b>Simon:</b><br>I tend to agree, however as you’ve seen UK mappers apply their perception of what a “place”, “city”, etc is and hence we have the wide range of tags already in use. Also given how widely addr:place is misused, I cannot see any sensible route back to using it exactly as you have within your proposed group of “8 tags rather than 13”. It would require a monumental task to clean up and ensure it is only used as intended going forward. Based on where we are now, I think a few extra tags is a good compromise and enables us to move forward without first having to unwind lots of edits from the previous X years.<br><br>One easy option to get the numbers down would be to strip out tags from what the Royal Mail (RM) refer to as the “Locality Elements” – that is addr:suburb, addr:hamlet, addr:village, addr:town and addr:city. RM have 3 tiers (locality, dependent locality, double dependent locality) so we cannot prune it back as far as just addr:suburb and addr:city but it could be pruned back to 3 tags. As with earlier comments, if someone wants to make a proposal to make some tags deprecated in the UK then feel free to. If doing that, you may want to read the emails from December that relate to the confusion between addr:city and a “Postal Town”.<br><br><b>Deprecation suggestions:</b><br>To recap, if anyone wants to take on the task of proposing deprecating some addr:tags to make further simplifications, then please feel free to. The above indicates that addr:flats, addr:terrace and some of the settlement hierarchy could all be deprecated. For now, whilst these tags have use in the UK, I will leave in the logic on how to interpret these to produce an addressed envelope.<br><br>If nobody comes forward to make these deprecation proposals, then I might add a “Tags (probably) to avoid” section on the Wiki page to at least capture that some of us think a few extra tags should be avoided.<br><div><br></div><div><b>Closing remarks:</b><br></div>I hope these responses help. I share your pain here as it is a lot more complex than it should have been. I just don’t see any way to get back to the basic ideal of 8 tags (plus 1 for “double dependent locality”) that we could have had if we had just followed the RM method from day one of address mapping in OSM! I therefore think that the wiki page is the best compromise we can manage at this stage (subject to anyone following up on the deprecation suggestions) reflecting the tags in use and the tags that people are likely to continue to use if they continue to apply their perception to what the words mean.<br><br>Best regards<br><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><span style="color:rgb(0,0,255)"><b>Rob</b></span><br></div></div></div></div></div></div>