<div dir="ltr">
<span></span>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
Hi all,</p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
<br>
</p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
As promised, a set of responses to your points. I’ve consolidated
them all together into one email so it’s very long (sorry about
that)!</p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
<br>
</p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
And then below all of that, much of which is me bemoaning over how
the addr:place tag could have worked if we’d got to defining UK
standards earlier on, I have a new proposal for your consideration.
But first, the responses to you:</p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
<br>
</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><br>
</p>
<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>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><br>
</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><br>
</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><b>Sarah Hoffman:</b></p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%">I hear you loud and
clear that “addr:place is meant to be used when the address does
not reference a</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%">street at all”. As
noted above I don’t really get that myself as it feels like it was
added without consideration for these parent+child type addresses we
have in the UK where the child element might not be a street (e.g.
could be a terrace, the name of a retail park, etc). Alas as you
noted, the addr:place tag is often incorrectly used and, whilst I’d
like to see that cleaned up in the UK, it is unrealistic to change it
globally. If it is assumed to be _after_ the <span style="text-decoration:none">street
in the global usage then clearly the UK is going to need a new tag as
it is not possible to get our address system into the existing
(globally used) addr:* tags. :-(</span></p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><br>
</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><span style="text-decoration:none">On
“But so far I have yet to see two streets as an official part of
the address” see example E provided by Robert Whittaker. I don’t
know how Royal Mail handled this as they only have “thoroughfare”
and “dependent thoroughfare” so don’t have a third element to
handle this case. I suspect they put the so-called parent street (i.e
Flag Hill) into their “locality elements” basically treating Flag
Hill as a region rather than as a street. </span><span style="text-decoration:none">Further
musings: Flag Hill probably started life as an non-street feature
(i.e. a place) before it’s name somehow got put on what looks like
a street name sign.</span></p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><br>
</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><span style="text-decoration:none">The
QA tool is fantastic by the way. Thanks for sharing this link Sarah
as I hadn’t seen it before.</span></p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><br>
</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><br>
</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><b><span style="text-decoration:none">Robert
Whittaker:</span></b></p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><span style="text-decoration:none">If
we adopt something like </span><span style="text-decoration:none">addr:street
< addr:place < addr:parentstreet </span><span style="text-decoration:none">as
the hierarchy then we have three layers (grandchild, child, parent to
extend the description). Personally I am not sure why we feel the
need for this in OpenStreetMap given that others (e.g. Royal Mail)
cope with just two. I suspect it is because they are happy to use
“thoroughfare”/”dependent thoroughfare” to refer to
non-street features, whereas here in the OpenStreetMap community we
don’t want “street” to refer to anything other than a feature
tagged highway=*. I theorise this is exactly the reason why all these
other tags (addr:terrace, addr:site, etc) have been created by
mappers.</span></p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><br>
</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><span style="text-decoration:none">I
</span><span style="text-decoration:none">also worry about the case
where you describe </span><span style="text-decoration:none">t</span><span style="text-decoration:none">he
right way of mapping something as using addr:place and
addr:parentstreet but omitting addr:street entirely. Your example C
fits in here. What happens if a mapper comes along and adds
addr:street=London Road as is perfectly doable using the existing map
editors. Then when you parse the address onto the envelope you end up
with London Road being duplicated:</span></p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><br>
</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%">Currys</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%">Unit 1</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%">London Road</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%">Forest Retail Park</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%">London Road</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%">Thetford</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%">IP24 3QL</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><br>
</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%">We could of course
get around that by saying “if addr:street=addr:parentstreet then
omit addr:street from envelope address” but as others have said, we
are not the only ones working with addresses so whilst we can
implement a fix, many data users wouldn't.</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><br>
</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%">In your example F
you are assuming it is always a building or group of buildings. This
is not always the case as it could be the name of a
Business/Technology Park as in the example “Co-operative House,
Warwick Technology Park, Gallows Hill” where Gallows Hill is the
street. It seems like in this case you are suggesting that we drop
back to the Example C style of using addr:place with
addr:parentstreet.</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><br>
</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%">FWIW, Church
Cottages in Example F is in keeping with addr:place in my mind as it
is a “Part of address, which is not related to street, but to some
territorial zone, linear object, node or some abstract object”. The
object in question being the building / land area on which the
cottages sit. Again, I think this is where our communities differing
judgement of what is what hasn’t helped us versus RM’s approach
of parent+child regardless of whether the element is a street or
non-street feature.</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><br>
</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%">Finally in your
example D, “Futura Park” is not part of what we will be asking
contributors to provide in our simplified map editor. It does not
form part of the bit of the address above the settlement/locality
part on the envelope. I suspect RM have included in in their
“Locality Elements” (as a Dependent Locality) rather than in
their “Thoroughfare Elements”. Quite frankly I have no idea why
as there is only one James Bennett Avenue in Ipswich so no need for
Futura Park to appear on the envelope at all. Trying to recreate this
in OSM feels too close to trying to recreate the RM database which is
not what we are doing or want to do.</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><br>
</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><br>
</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><b>Nick (Foresters):</b></p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%">Of BS7666, I suspect
you mean “Part 5: Specification for a delivery point gazetteer”.
It shouldn’t surprise to hear it is very aligned to RM/PAF’s
“thoroughfare” (parent) and “dependent thoroughfare” (child),
although BS7666 uses different terminology.</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><br>
</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%">Stick “Open UPRN”
into your favourite search engine for a source of UPRN points under
the Open Government Licence. We plan to add those that have a one to
one mapping between UPRN and Cadastral Parcel.</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><br>
</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><br>
</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><b>Peter Neale:</b></p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%">I have fixed the
taginfo stats on that wiki page. As noted above, this works well when
the parent and child elements are both streets, but we’ve tied
ourselves in knots when either is some non-street feature (dare I say
a “place”!)</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><br>
</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><br>
</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><b>Neil Matthews
(2):</b></p>
<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.</p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
<br>
</p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
<br>
</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><b>Dave F:</b></p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
Yeah, as noted above we do seem to have many tags that act as a
(child) supplement to addr:street. The addr:terrace tag is one such
example. I would have thought it would be better to have just one
which works well for all types of feature (street or non-street
features) but at the moment that doesn’t seem to be the case.</p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
<br>
</p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
If you pan around in the Devizes area, you’ll see it is not always
one building. I screen-grabbed that one as it was easiest to show.
Others are multiple buildings around a courtyard or similar
non-street abstract concept.</p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
<br>
</p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
<br>
</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><b>Jerry:</b></p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
The aim is not to replicate RM, instead it is to have a process where
we can take OSM addr:* tags and be able to write an address on an
envelope. The current soup of tags is making this hard. A secondary
aim is to enable new mappers to easily collect addresses, including
those that have a parent+child component without them having to spend
ages reading about all the tagging options and nuances.</p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
<br>
</p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
Interestingly it sounds like you’re using addr:place in Nottingham
as I best understand the tag to be, however it seems like Nottingham
doesn’t then have any case where a streetname would appear on the
envelope after the place name. This is not the case in other towns as
highlighted by some of the examples already given.</p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
<br>
</p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
<br>
</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><b>Mark Goodge:</b></p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
Why not the following for that example:</p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
<br>
</p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
addr:housename "Flacks Farm"</p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
addr:housenumber "43"</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><span style="font-weight:normal">addr:place
"Sedge Fen"</span></p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
addr:village "Lakenheath"</p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
addr:town "Brandon"</p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
addr:county "Suffolk"</p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
addr:postcode "IP27 9lG"</p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
<br>
</p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
That seems more in keeping with the way the tags are described as I
read them. It would also parse properly onto an envelope (with “43
Sedge Fen” appearing on one line) if my logic is followed. [Clearly
that is not going to be the case as addr:place is a mess so that
might have to become some other tag new for the UK].</p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
<br>
</p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
<br>
</p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
====</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><b>A new proposal:</b></p>
<p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
<br>
</p>
<ol><li><p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
Several have noted that they don’t want addr:street to be used for
child elements that are not street.</p>
</li><li><p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
Alternatives exist but are feature specific so complicated for new
mappers to understand and make user interfaces significantly harder
than they need to be. Examples include addr:terrace and addr:site.
Neither are globally accepted tags.</p>
</li><li><p style="margin-bottom:0cm;font-weight:normal;line-height:100%;background:transparent none repeat scroll 0% 0%">
Whilst it felt like addr:place was a good common tag, locally this
tag is inconsistently used and globally it tends to be used for
address components that appear after addr:street on the envelope not
before.</p>
</li><li><p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><span style="font-weight:normal">As
such we need a new tag for capturing data before the street (or can
be used when street not present at all). If addr:housenumber is used
then this new tag should appear on the same line as the housenumber
if written out on an envelope. </span><span style="font-weight:normal">To
align with </span><span style="font-weight:normal">the term used in</span><span style="font-weight:normal">
BS7666 </span><span style="font-weight:normal">I</span><span style="font-weight:normal">
propose using addr:substreet and defining it as:</span></p>
<ol type="a"><li><p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><span style="font-weight:normal">Definition for tag: Used
when delivery points are grouped by some feature before, or instead
of, a street. For example “West Business Park”, “South Retail
Park”, “Castle Mews”, “The Cross”, “</span>University
Park”, “Church Cottages”. Can also be used when a feature has
two streets in it’s address. In this case, use addr:substreet for
the one that appears first on an address line, and
addr:parentstreet for the second.</p>
</li><li><p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%">Note 1: the
use of “or instead of” in the above description means that
addr:substreet can be used for non-street features where a
streetname is not part of the address. That is, it can be used
inplace of addr:place.</p>
</li><li><p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%">Note 2: Personally, it
probably makes sense to stop using (and phase down use of) addr:place in the UK given how inconsistently it is used.
Nevertheless I have tried to come up with a way of using it on an
envelope that might (?) work (see below). It would be good to hear feedback on
this. Is it time to move on from that tag in the UK?</p>
</li></ol>
</li><li><p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%">As a bit of a
compromise, if people want to continue using a more feature specific
tag for the child element (e.g. addr:terrace if the feature is a
terrace) then they can continue to do so but when producing an
address for an envelope, if both addr:substreet and addr:terrace
exist then then value in addr:substreet will be used.</p>
</li></ol>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><br>
</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><span style="font-weight:normal">Using
this proposal addresses the issues identified (pun unintended). Rules
</span><span style="font-weight:normal">for taking OpenStreetMap
tags and converting them to the address lines written on an envelope
are: </span>
</p>
<p style="margin-bottom:0cm;line-height:100%;background:transparent none repeat scroll 0% 0%"><br>
</p>
<ol><li><p style="margin-bottom:0cm;line-height:115%;background:transparent none repeat scroll 0% 0%">Tag pre-processing steps (outside
OSM):</p>
<ol><li><p style="margin-bottom:0cm;line-height:115%;background:transparent none repeat scroll 0% 0%">If <code class="gmail-western" style="font-family:"Liberation Mono",monospace">addr:</code><code class="gmail-western" style="font-family:"Liberation Mono",monospace"><font face="Liberation Mono, monospace">substreet</font></code>
is null, then set <code class="gmail-western" style="font-family:"Liberation Mono",monospace">addr:</code><code class="gmail-western" style="font-family:"Liberation Mono",monospace"><font face="Liberation Mono, monospace">substreet</font></code>
equal to <code class="gmail-western" style="font-family:"Liberation Mono",monospace">addr:terrace</code></p>
</li><li><p style="margin-bottom:0cm;line-height:115%;background:transparent none repeat scroll 0% 0%">If <code class="gmail-western" style="font-family:"Liberation Mono",monospace">addr:</code><code class="gmail-western" style="font-family:"Liberation Mono",monospace"><font face="Liberation Mono, monospace">substreet</font></code>
is equal to <code class="gmail-western" style="font-family:"Liberation Mono",monospace">addr:</code><code class="gmail-western" style="font-family:"Liberation Mono",monospace"><font face="Liberation Mono, monospace">street</font></code>
then set <code class="gmail-western" style="font-family:"Liberation Mono",monospace">addr:</code><code class="gmail-western" style="font-family:"Liberation Mono",monospace"><font face="Liberation Mono, monospace">street</font></code>
equal to null.</p>
</li><li><p style="margin-bottom:0cm;line-height:115%;background:transparent none repeat scroll 0% 0%">If <code class="gmail-western" style="font-family:"Liberation Mono",monospace">addr:</code><code class="gmail-western" style="font-family:"Liberation Mono",monospace"><font face="Liberation Mono, monospace">parentstreet</font></code>
is equal to <code class="gmail-western" style="font-family:"Liberation Mono",monospace">addr:</code><code class="gmail-western" style="font-family:"Liberation Mono",monospace"><font face="Liberation Mono, monospace">street</font></code>
then set <code class="gmail-western" style="font-family:"Liberation Mono",monospace">addr:</code><code class="gmail-western" style="font-family:"Liberation Mono",monospace"><font face="Liberation Mono, monospace">street</font></code>
equal to null.</p>
</li></ol>
</li><li><p style="margin-bottom:0cm;line-height:115%;background:transparent none repeat scroll 0% 0%">Writing the address as appears on
an envelope:</p>
<ol><li><p style="margin-bottom:0cm;line-height:115%;background:transparent none repeat scroll 0% 0%">Recipients name goes on line 1
(not in OSM database so we skip this line)</p>
</li><li><p style="margin-bottom:0cm;line-height:115%;background:transparent none repeat scroll 0% 0%">Next print the Premise and
Thoroughfare elements:</p>
<ol><li><p style="margin-bottom:0cm;line-height:115%;background:transparent none repeat scroll 0% 0%">On the next line, print
“Sub-part” <code class="gmail-western" style="font-family:"Liberation Mono",monospace">addr:unit</code> and “House
/ Building name” <code class="gmail-western" style="font-family:"Liberation Mono",monospace">addr:housename</code>
(separated by a space). If either are missing, just skip that but
print the other part (e.g. show just “House / Building name”
if no “sub-part” present.
</p>
</li><li><p style="margin-bottom:0cm;line-height:115%;background:transparent none repeat scroll 0% 0%">On the next line, print “Number”
<code class="gmail-western" style="font-family:"Liberation Mono",monospace">addr:housenumber</code> and “Sub-street”
<code class="gmail-western" style="font-family:"Liberation Mono",monospace">addr:</code><code class="gmail-western" style="font-family:"Liberation Mono",monospace"><font face="Liberation Mono, monospace">substreet</font></code>
(separated by a space). If “Sub-street” does not exist, then
print “Number” <code class="gmail-western" style="font-family:"Liberation Mono",monospace">addr:housenumber</code>
and “Streename” <code class="gmail-western" style="font-family:"Liberation Mono",monospace">addr:street</code>
instead (separated by a space). If “Number” <code class="gmail-western" style="font-family:"Liberation Mono",monospace">addr:housenumber</code>
is missing, skip but print the other part.
</p>
</li><li><p style="margin-bottom:0.25cm;line-height:115%;background:transparent none repeat scroll 0% 0%">On the next line, print “Streetname” <code class="gmail-western" style="font-family:"Liberation Mono",monospace">addr:street</code>
(unless this has already been printed in previous step)</p>
</li><li><p style="margin-bottom:0.25cm;line-height:115%;background:transparent none repeat scroll 0% 0%">On the next line, print “Parent street”
<code class="gmail-western" style="font-family:"Liberation Mono",monospace">addr:parentstreet</code>.</p>
</li></ol>
</li><li><p style="margin-bottom:0.25cm;line-height:115%;background:transparent none repeat scroll 0% 0%">Next print the Locality elements:</p>
<ol><li><p style="margin-bottom:0.25cm;line-height:115%;background:transparent none repeat scroll 0% 0%">Print lines with one item per line in the following order,
skipping any missing tags or any repeat occurrences of a
previously used tag value. Order is <code class="gmail-western" style="font-family:"Liberation Mono",monospace">addr:</code><code class="gmail-western" style="font-family:"Liberation Mono",monospace">place</code><code class="gmail-western" style="font-family:"Liberation Mono",monospace"><font face="Liberation Mono, monospace">,
</font></code><code class="gmail-western" style="font-family:"Liberation Mono",monospace">addr:</code><code class="gmail-western" style="font-family:"Liberation Mono",monospace"><font face="Liberation Mono, monospace">suburb,
</font></code><code class="gmail-western" style="font-family:"Liberation Mono",monospace">addr:</code><code class="gmail-western" style="font-family:"Liberation Mono",monospace"><font face="Liberation Mono, monospace">hamlet</font></code><code class="gmail-western" style="font-family:"Liberation Mono",monospace">,
addr:</code><code class="gmail-western" style="font-family:"Liberation Mono",monospace"><font face="Liberation Mono, monospace">village</font></code><code class="gmail-western" style="font-family:"Liberation Mono",monospace">,</code><code class="gmail-western" style="font-family:"Liberation Mono",monospace"><font face="Liberation Mono, monospace">
</font></code><code class="gmail-western" style="font-family:"Liberation Mono",monospace">addr:town, addr:city</code></p>
</li></ol>
</li><li><p style="margin-bottom:0.25cm;line-height:115%;background:transparent none repeat scroll 0% 0%">Finally print the postcode and (if required) country
elements:</p>
<ol><li><p style="margin-bottom:0.25cm;line-height:115%;background:transparent none repeat scroll 0% 0%">On the next line, print <code class="gmail-western" style="font-family:"Liberation Mono",monospace">addr:</code><code class="gmail-western" style="font-family:"Liberation Mono",monospace">postcode</code></p>
</li><li><p style="margin-bottom:0.25cm;line-height:115%;background:transparent none repeat scroll 0% 0%">On the last line, print <code class="gmail-western" style="font-family:"Liberation Mono",monospace">addr:c</code><code class="gmail-western" style="font-family:"Liberation Mono",monospace">ountry</code>
</p>
</li></ol>
</li></ol>
</li></ol>
<p style="margin-bottom:0.25cm;line-height:115%;background:transparent none repeat scroll 0% 0%">I think this is the best I can do unless we are willing to use
some of the existing tags to capture the child part of an address
even if the child feature is not the same feature type as the tag
(i.e. not a street if using add:street as the child, or not a terrace
if using addr:terrace as the child).</p>
<p style="margin-bottom:0.25cm;line-height:115%;background:transparent none repeat scroll 0% 0%">As always feedback is welcome but all the same caveats about not
being able to deliver miracles apply. For info I spent the best part
of a full working day on this today such is the complexity of it all
:-(</p><p style="margin-bottom:0.25cm;line-height:115%;background:transparent none repeat scroll 0% 0%">Thank you if you managed to read this far!<br></p>
<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><br></div><div>P.S. The OSM UK address editor won't ask people to contribute any of what RM call "locality elements" as often these cannot be surveyed on the ground, unlike streetnames and numbers. I'm therefore paying slightly less attention to those points in this thread but am reading them all.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 22 Dec 2021 at 08:43, Rob Nickerson <<a href="mailto:rob.j.nickerson@gmail.com">rob.j.nickerson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Thanks for all the comments so far. Please keep them coming.<div dir="auto"><br></div><div dir="auto">Just to be clear, we are not trying to replicate the way Royal Mail or PAF do it. Instead what we want is to define a way in which someone can take the addr tags and write out an address on an envelope. Currently this doesn't seem possible in a consistent way.</div><div dir="auto"><br></div><div dir="auto">Personally I was hoping to do this using existing tags rather than creating new ones. I know this will result in some work changing a few things to conform to the new standard but introducing new tags would also create work for existing OSM features.</div><div dir="auto"><br></div><div dir="auto">For context, 17 years of OSM has led us to mapping (inconsistently) just around 2.5million addresses. In total UK has 27 million residential addresses plus unknown millions of non-residential addressees.</div><div dir="auto"><br></div><div dir="auto">Hopefully we can find a solution that breaks as little as possible and results in as little re-work as possible but we need to be realistic that there is no silver bullet that solves everything without breaking anything.</div><div dir="auto"><br></div><div dir="auto">Let's get this right now so that we can confidently map the other 25+ million addressees knowing we're using a system where is possible to use OSM to write an envelope.</div><div dir="auto"><br></div><div dir="auto">I'll end by saying that, despite not aiming to replicate RM/PAF, it does seem that we will need a way of recording the parent+child type arrangement. Because this hasn't been agreed across the UK community to date, we now have more and more tags being created (e.g. addr:terrace, addr:site, addr:parentstreet, addr:locality). I suspect some have been created because the child element is not a street and hence people don't want to use the addr:street+addr:parentstreet combination. Do we need to clarify that addr:street can be used for non-street child elements or is that a no-go as well?</div><div dir="auto"><br></div><div dir="auto">P.s. I'll respond to the ideas received in another email.</div><div dir="auto"><br></div><div dir="auto">Best regards</div><div dir="auto">Rob</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 21 Dec 2021, 17:03 Rob Nickerson, <<a href="mailto:rob.j.nickerson@gmail.com" target="_blank">rob.j.nickerson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi all,</div><div><br></div><div>I hope many of you are now managing to relax and enjoy the Christmas break. For those still working, I hope it drops away soon and you are able to enjoy a break soon.</div><div><br></div><div>As previously discussed, OSM UK is running a project to make it easier to collect address data in the UK. As a quick recap, the aim is to create a simple user interface where anyone (existing and new mappers) can add address data. The interface will be populated with a series of points where we believe there to be an address (filtered to avoid duplication with any existing OSM data) and the user will be asked to input the top part of the address.</div><div><br></div><div>One of the challenges we have is making sure that the right part of the address is assigned to the right addr:* tag in OpenStreetMap. We have therefore been studying the address tags and how they are used in the UK. Suffice to say it is not straightforward and without its inconsistencies. I have therefore produced the following wiki page to help other mappers understand the soup of available tags and which are better / worse to use.<br></div><div><br></div><div><a href="https://wiki.openstreetmap.org/wiki/Addresses_in_the_United_Kingdom" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/wiki/Addresses_in_the_United_Kingdom</a> <br></div><div><br></div><div>You will see on the page that one of the concepts we struggle with is when you need both a parent and child part of the local area to describe a complete address. In Royal Mail's language they use a "thoroughfare" and "dependent thoroughfare" whilst in OpenStreetMap we seem to have multiple tag options. For the OSM UK project we want to keep it simple and not bombard new mappers with the details of conflicting / inconsistent OSM tags. As such we plan to use addr:place (child) and addr:street (parent) for these parent and child relationships.</div><div><br></div><div>Please let me know if you have any feedback. I will try my utmost to take this on board but a word of warning: I have found OSM tags to be inconsistent and not straightforward. I will try my best but cannot work miracles even at this time of the year!<br></div><div><br></div><div>P.S. The wiki page is very much focussed on the top part of an address. This is intentional as it is what we will focus on in the OSM UK project. These address parts require ground survey (or local knowledge) whereas some of the lower elements of an address can be determined by admin boundaries / nearness to existing OSM data.<br></div><div><br></div><div>Thank you<br></div><div><div><div dir="ltr"><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></div>
</blockquote></div>
</blockquote></div>