<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <blockquote type="cite"
cite="mid:CAK4yQTm7d-e6OMGFm-YLaADuGQCW8ZEAxDDW-CSqur8PhSGddw@mail.gmail.com">
      <div dir="ltr">
        <p
          style="margin-bottom:0cm;line-height:100%;background:transparent
          none repeat scroll 0% 0%"><b>Neil Matthews
          </b><b>(1)</b><b>:</b> </p>
        <p
          style="margin-bottom:0cm;line-height:100%;background:transparent
          none repeat scroll 0% 0%">Yes, I saw the wiki
          stated “No object should have addr:place=* and addr:street at
          the
          same time” and referenced this in wiki page. Personally I
          think
          whoever wrote this did so not realising that it is perfectly
          possible
          to have a non-street child element and a street parent element
          and
          that the way addr:place is described is basically exactly how
          you’d
          describe such a non-street child element. Alas we now have to
          cope
          with our prior decisions and subsequent mess in the addr:place
          tag!</p>
      </div>
    </blockquote>
    <p>I think you've ignored the fact that existing validators will
      have to be reworked specifically for UK addresses too.<br>
    </p>
    <blockquote type="cite"
cite="mid:CAK4yQTm7d-e6OMGFm-YLaADuGQCW8ZEAxDDW-CSqur8PhSGddw@mail.gmail.com">
      <div dir="ltr"><b>Neil Matthews
          (2):</b>
        <p
style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent
          none repeat scroll 0% 0%">
          Can you expand on what you mean by “Add an addr:locality for
          your
          extreme cases” and how this differs from things like
          addr:suburb? I
          see that in the Robert W examples, you’d effectively be
          putting a
          road name (Flag Hill) into the addr:locality tag. As noted
          above, I
          suspect this is what RM is doing in their PAF as they only
          have the
          choice of 2 parts for their “thoroughfare” parent and child
          relationship. Obviously addr:locality would be ( / already is)
          a new
          tag outside of the global documented tags but sounds like we
          are
          heading that way as an inevitability anyway.<br>
        </p>
      </div>
    </blockquote>
    <p>As I added on the wiki discussion page there is probably a need
      to sub-divide:</p>
    <p>1). Add an area subdivision smaller than suburb<br>
    </p>
    <p>addr:locality < addr:suburb; more specifically define a
      smaller "area-based" tag (subset) for e.g. business parks,
      shopping areas, etc. where there will be name'd businesses inside
      addr:housename'd buildings on addr:street's<br>
      Note addr:locality is really a subset of suburb -- maybe even
      think of it as an "area" version of addr:place?<br>
      <br>
      2). Add a street subdivision:</p>
    <p>The addr:street < addr:parentstreet could be additionally be
      used for smaller "way-based" tag (subset) -- maybe even think of
      it as an "way" version of addr:place.<br>
      TBH my preference would be to keep the basic idea but to switch it
      around to be addr:substreet and addr:street (where addr:substreet
      is a more general and less architecture-specific version of
      addr:terrace). Also rendering software could treat substreet a bit
      like it does housename at present -- so it shows "#n (substreet)"
      -- without having to check if there is a parent.<br>
      <br>
      3). Maybe, one could think of the above as sort of addr:place by
      any other name but it doesn't reuse existing tags (with existing
      baggage) and invalidate existing validator software.</p>
    <p>Cheers,<br>
      Neil<br>
    </p>
  </body>
</html>