<div dir="auto"><div>Thanks for putting that list together Robert. Rob, I've mixed a reply to you into this.<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 23 Dec 2021, 13:29 Robert Whittaker (OSM lists), <<a href="mailto:robert.whittaker%2Bosm@gmail.com" rel="noreferrer noreferrer" target="_blank">robert.whittaker+osm@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><snip><br>
Fundamental Address Tenets:<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I broadly agree. At least, we need to be clear what the scope/uses are. It seems clear that at least one of 1.4 and 1.5 (UK-specific tags, redefining tags) can't hold and in that case I wouldn't assume missing only one was better than both.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">To make things easier for both Data Users and Mappers:<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">We probably can have a stable hierarchical list so probably should. An alternative might be an addr:order tag but I don't think we need to go there.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2.3/ Ideally, the arrangement of the tag values on an envelope (...)<br>
should be universal, ....<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">perhaps but that's already not the case.<br></div><div dir="auto"><br></div><div dir="auto">I would add that ideally we shouldn't redefine or add tags in ways that break existing software without buy-in from their developers. Therefore it's great having Sarah and Simon's involvement; it would be good if we could involve others rather than trying to guess what would be easiest to change.</div><div dir="auto"><br></div><div dir="auto">We seem to have 3 options for addresses with two things between name/number and locality:</div><div dir="auto">a:</div><div dir="auto">    housenumber street/place</div><div dir="auto">    parentstreet</div><div dir="auto">b:</div><div dir="auto">    housenumber substreet/[others such as terrace]</div><div dir="auto">    street</div><div dir="auto">c:</div><div dir="auto">    housenumber substreet/[others such as terrace]<br>    parentstreet</div><div dir="auto"><br></div><div dir="auto">The problem with a is the redefinition of street/place. The first problem with b and c are the addition of one or more new elements to the top line. Another problem with b is moving street down a line. Another problem with c is the absence of street/place, leading to guessing. There may be others! </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Are there any situations where this [see Robert's post] wouldn't work?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">As above, when the street/place doesn't fit the existing definition, especially if needing named houses (i.e you wouldn't want to put the terrace name as a house name and then the house name as a unit). </div><div dir="auto">Also, you don't necessarily need housename/number if you have a unit, as is often the case on industrial estates, unless housename/number should be used here.</div><div dir="auto"><br></div><div dir="auto">Happy holidays</div><div dir="auto"><br></div><div dir="auto">Tom</div></div>