[Talk-GB] OSM UK address project: tags

[Rob Nickerson]

Hi all,


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)!


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:



*Neil Matthews **(1)**:*

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!



*Sarah Hoffman:*

I hear you loud and clear that “addr:place is meant to be used when the
address does not reference a

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 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. :-(


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. 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.


The QA tool is fantastic by the way. Thanks for sharing this link Sarah as
I hadn’t seen it before.



*Robert Whittaker:*

If we adopt something like addr:street < addr:place < addr:parentstreet 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.


I also worry about the case where you describe the 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:


Currys

Unit 1

London Road

Forest Retail Park

London Road

Thetford

IP24 3QL


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.


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.


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.


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.



*Nick (Foresters):*

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.


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.



*Peter Neale:*

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”!)



*Neil Matthews (2):*

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.



*Dave F:*

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.


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.



*Jerry:*

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.


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.



*Mark Goodge:*

Why not the following for that example:


addr:housename "Flacks Farm"

addr:housenumber "43"

addr:place "Sedge Fen"

addr:village "Lakenheath"

addr:town "Brandon"

addr:county "Suffolk"

addr:postcode "IP27 9lG"


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].



====

*A new proposal:*



   1.

   Several have noted that they don’t want addr:street to be used for child
   elements that are not street.
   2.

   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.
   3.

   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.
   4.

   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. To align with the term used in BS7666 I propose
   using addr:substreet and defining it as:
   1.

      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”, “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.
      2.

      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.
      3.

      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?
      5.

   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.


Using this proposal addresses the issues identified (pun unintended). Rules for
taking OpenStreetMap tags and converting them to the address lines written
on an envelope are:



   1.

   Tag pre-processing steps (outside OSM):
   1.

      If addr:substreet is null, then set addr:substreet equal to
      addr:terrace
      2.

      If addr:substreet is equal to addr:street then set addr:street equal
      to null.
      3.

      If addr:parentstreet is equal to addr:street then set addr:street
      equal to null.
      2.

   Writing the address as appears on an envelope:
   1.

      Recipients name goes on line 1 (not in OSM database so we skip this
      line)
      2.

      Next print the Premise and Thoroughfare elements:
      1.

         On the next line, print “Sub-part” addr:unit and “House / Building
         name” addr:housename (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.
         2.

         On the next line, print “Number” addr:housenumber and “Sub-street”
         addr:substreet (separated by a space). If “Sub-street” does not
         exist, then print “Number” addr:housenumber and “Streename”
         addr:street instead (separated by a space). If “Number”
         addr:housenumber is missing, skip but print the other part.
         3.

         On the next line, print “Streetname” addr:street (unless this has
         already been printed in previous step)
         4.

         On the next line, print “Parent street” addr:parentstreet.
         3.

      Next print the Locality elements:
      1.

         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 addr:place, addr:suburb, addr:hamlet, addr:
         village, addr:town, addr:city
         4.

      Finally print the postcode and (if required) country elements:
      1.

         On the next line, print addr:postcode
         2.

         On the last line, print addr:country

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).

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 :-(

Thank you if you managed to read this far!
*Rob*

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.

On Wed, 22 Dec 2021 at 08:43, Rob Nickerson <rob.j.nickerson at gmail.com>
wrote:

> Thanks for all the comments so far. Please keep them coming.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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?
>
> P.s. I'll respond to the ideas received in another email.
>
> Best regards
> Rob
>
> On Tue, 21 Dec 2021, 17:03 Rob Nickerson, <rob.j.nickerson at gmail.com>
> wrote:
>
>> Hi all,
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> https://wiki.openstreetmap.org/wiki/Addresses_in_the_United_Kingdom
>>
>> 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.
>>
>> 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!
>>
>> 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.
>>
>> Thank you
>> *Rob*
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-gb/attachments/20211222/dcc64923/attachment-0001.htm>