<div dir="ltr">Evening.<br><br>Just to clarify, as there does seem to be some confusion today:<br><br>The majority of addresses will be simple housenumber/name and street name. It is the cases where a child+parent relationship is needed that is causing the trouble. Options discussed are:<br><br>1. Child = addr:place, Parent = addr:street -> discounted because these tags shouldn’t appear together.<br><br>2. Child = addr:terrace, Parent = sometag -> Already being used by some mappers in the UK. Only works if the child feature is a terrace therefore is not feature agnostic. Some mappers have suggested deprecating use of addr:terrace in the UK.<br><br>3. Child = addr:street, Parent = addr:parentstreet -> Already being used by some mappers in the UK. Only works if the child feature is a street therefore is not feature agnostic. Note that some mappers have suggested using this even if the child feature is not a street but others have disagreed and said addr:street should only be used for highway=* objects.<br><br>4. Child = addr:substreet, Parent = addr:parentstreet -> The child tag is proposed as a feature agnostic tag that overcomes the concerns raised about the feature specific tags in 2 and 3. Unfortunately introduces new UK tags.<br><br>5. Child = addr:place, Parent = addr:parentstreet -> We know that currently the addr:place tag is very misused in the UK (and globally) as mappers mix it up with addr:suburb. <br><br><br>Of these, 4 and 5 seem to be the ones being most discussed. I do understand the idea behind option 5 as it is very close to my original proposal (just with a different parent tag) and only introduces one new UK specific tag. However, it is not without its issues. Primarily we have seen that addr:place is very badly misused in the UK with a long way to go to clean up the tag [A]. Given the UI of some editing tools, I am not sure we will ever properly clear addr:place up – after all what proportion of contributors are reading these lengthy talk-gb posts or the wiki pages! Furthermore it would introduce a weird nuance to the definition of place; namely “addr:place is meant to be used when the address does not reference a street at all, except when the street is a parent street and you tag it with addr:parentstreet”.<br><br>Consequently I believe that option 4 is a much more pragmatic solution. We will know exactly what people mean when they use this tag, which is not the case for addr:place. In a way, this reminds me very much of the time when we were struggling with Public Rights of Way mapping. There were those that argued for an approach based on the original meaning / intent of a tag, but at the end of the day, the only way to pragmatically solve the issue was to introduce the designation=public_footpath (and so on) tags. These removed all ambiguity of the other inconsistently used / interpreted tags.<br><br>I appreciate that this runs counter to Sarah’s note that “Data users will thank you if you go for one or the other, not both” but I cannot help but think that some data users will also thank us if we use a tag that is consistently used. I suspect that some use cases will require this consistency more than others.<br><br>We have a little time before the OSM UK address editor is ready so it is always possible to revisit this decision if we make big inroads into cleaning up the use of addr:place. (I will try my best to fix any wrong addr:place tags I have introduced).<br><br>It’s never nice to end on a compromise, so it is worth reflecting on some of the wins we have made along the way:<br><br>    1. We’ve learned a lot about addr:place and some mappers have already started correcting their edits to use addr:suburb in cases where this is now understood to be the right tag.<br>    2. We’ve (re-)discovered the meaning of addr:city which should result in less use of addr:village, addr:town (both not globally accepted tags).<br>    3. We’ve identified a whole range of tags to avoid in the UK (addr:locality, addr:site, addr:subdistrict, addr:district, addr:province, addr:state, addr:country) and some to possibly avoid.<br>    4. We’ve become aware of the nominatim QA tool which should keep us on track in the future and help us to fix our errors of the past.<br><br>Finally I want to apologise to anyone who feels they have come out on the wrong side of this compromise. Like I said in December “we need to be realistic that there is no silver bullet that solves everything without breaking anything”. If you feel that you’ve been caught in the crossfire of my non-silver bullet then I am sorry. Hopefully we can all chuckle about this when we have mapped all 27 million residential addresses thereby making one of the UK’s hold out closed datasets open to everyone :-)<br><br>Thanks<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></div><div dir="ltr"><span style="color:rgb(0,0,255)"><b><br></b></span></div>[A] <a href="https://nominatim.org/qa/#map=8.06/51.79/-2.08&layer=addr_place_and_street">https://nominatim.org/qa/#map=8.06/51.79/-2.08&layer=addr_place_and_street</a></div></div></div></div></div>