[Talk-GB] OSM UK address project: tags - Updated guidance

[Rob Nickerson]

 Hi all,

A few more responses.

*Rick:*
On the topic of addr:flats and addr:unit I also feel it is silly to have
two choices here. I think if you look at Simon’s messages to this thread
then you will see that there is similar excess of tags in other places too.
The only reason I can think of for this is that the tags use words that we
all apply our own personal and subjective interpretation to. In this case
mappers probably see “unit” more as an industrial sub part of a building,
whilst “flat” is seen as a domestic sub part of a building. Both cases are
just trying to say “sub part” but unfortunately we now have two tags. Let's
just hope nobody introduces addr:apartment as it seems to be popular to
call flats apartments these days!

It’s exactly the same for addr:hamlet, addr:village and addr:town. That is,
people read addr:city, applied their view of what a “city” is and decided
to create other tags. Same for addr:suburb and hence addr:locality gets
invented and used.

The OSM UK project will use addr:unit for single addresses when a sub part
is needed. The best advice I can give is to help clean up incorrect
addr:flats tags and if any addr:unit tags are used for multiple addresses,
then split them out into individual addressees.

If somebody wants to raise a proposal to make addr:flats deprecated in the
UK then please proceed. You have my vote (just that I am not going to raise
that myself as already in deeper than I had planned).

*Robert:*
I agree that if any of the child tags (addr:substreet, addr:terrace,
addr:street) are used, then the parent element should be in addr:street. As
such I agree that it is an “error for an object to have more than one of
addr:street, addr:place, addr:substreet and addr:terrace”. I drafted the
wiki page to cope with cases where people break this rule as I suspect that
will happen regardless of whether that text is included or not.

On the question “I also wonder whether we need to include addr:terrace as
an option, now we have addr:substreet”: I agree. I personally won’t be
using addr:terrace and the OSM UK editing tool won’t either because asking
people to pick a “feature specific” child tag is overly complex for the
tool we are making. Same comment I made above to Rick: If someone wants to
propose deprecating this addr:terrace tag in the UK then please feel free
to.

As for addr:locality I think you can guess my response. It is one of these
cases where I feel mappers have applied their perception of what a “suburb”
is and therefore created a new tag. addr:suburb is sufficient as a general
“sub area (i.e. locality) of a settlement regardless of the size of the
settlement” type tag. Why do you feel you need something different to
addr:suburb?

Finally, regarding the position of addr:place before or after
addr:parentstreet, then I suspect based on what Sarah said about most
people using addr:place when they should have used addr:suburb, that after
parent street is best. Either way, addr:place is a big mess in the UK and
hence the call on the wiki page to clean it up. Only by doing that will
data consumers get a better result. For your specific example of an
industrial estate off a main street, then I’d use addr:substreet +
addr:parentstreet. Implying place is a “child” feature was widely disliked
when the “parent” feature was addr:street. I suspect that dislike continues
with addr:parentstreet too.

*Simon:*
I tend to agree, however as you’ve seen UK mappers apply their perception
of what a “place”, “city”, etc is and hence we have the wide range of tags
already in use. Also given how widely addr:place is misused, I cannot see
any sensible route back to using it exactly as you have within your
proposed group of “8 tags rather than 13”. It would require a monumental
task to clean up and ensure it is only used as intended going forward.
Based on where we are now, I think a few extra tags is a good compromise
and enables us to move forward without first having to unwind lots of edits
from the previous X years.

One easy option to get the numbers down would be to strip out tags from
what the Royal Mail (RM) refer to as the “Locality Elements” – that is
addr:suburb, addr:hamlet, addr:village, addr:town and addr:city. RM have 3
tiers (locality, dependent locality, double dependent locality) so we
cannot prune it back as far as just addr:suburb and addr:city but it could
be pruned back to 3 tags. As with earlier comments, if someone wants to
make a proposal to make some tags deprecated in the UK then feel free to.
If doing that, you may want to read the emails from December that relate to
the confusion between addr:city and a “Postal Town”.

*Deprecation suggestions:*
To recap, if anyone wants to take on the task of proposing deprecating some
addr:tags to make further simplifications, then please feel free to. The
above indicates that addr:flats, addr:terrace and some of the settlement
hierarchy could all be deprecated. For now, whilst these tags have use in
the UK, I will leave in the logic on how to interpret these to produce an
addressed envelope.

If nobody comes forward to make these deprecation proposals, then I might
add a “Tags (probably) to avoid” section on the Wiki page to at least
capture that some of us think a few extra tags should be avoided.

*Closing remarks:*
I hope these responses help. I share your pain here as it is a lot more
complex than it should have been. I just don’t see any way to get back to
the basic ideal of 8 tags (plus 1 for “double dependent locality”) that we
could have had if we had just followed the RM method from day one of
address mapping in OSM! I therefore think that the wiki page is the best
compromise we can manage at this stage (subject to anyone following up on
the deprecation suggestions) reflecting the tags in use and the tags that
people are likely to continue to use if they continue to apply their
perception to what the words mean.

Best regards
*Rob*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-gb/attachments/20220105/5c960e90/attachment-0001.htm>