[Talk-GB] OSM UK address project: tags

Peter Neale nealepb at yahoo.co.uk
Tue Dec 21 19:54:25 UTC 2021


As my 2p-worth in this debate, I cannot do more than refer to my (stalled) proposal at:
https://wiki.openstreetmap.org/wiki/Proposed_features/Proposal_to_Document_the_Key_%22addr:parentstreet%22

I am not clear why, in that proposal, it says that TagInfo says that there are no occurences of "addr:parentstreet".  When I seach in TagIfo, I find 5,700 instances.  Perhaps I made a mistake in inserting the TagInfo reference?
Regards,Peter
(PeterPan99) 

    On Tuesday, 21 December 2021, 19:32:48 GMT, Robert Whittaker (OSM lists) <robert.whittaker+osm at gmail.com> wrote:  
 
 On Tue, 21 Dec 2021 at 16:08, Rob Nickerson <rob.j.nickerson at gmail.com> wrote:

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

I'm afraid I disagree with the conclusion that we don't need both
addr:parentstreet and addr:place. I think there is a legitimate place
for using both of these in conjunction with addr:street. Usually an
address would only use two out of the three, but there are some cases
where you might need all three.

First, I think we need to define the ordering of these tags within an
address. This ensures we can consistently parse them into the full
address whenever they appear. I would propose that we adopt:
addr:street < addr:place < addr:parentstreet . (Note that this has
addr:street and addr:place the opposite way round from the suggestion
in the wiki page above. The reason for this is explained further
down.) Now we can consider some of the different address types we need
to be able to capture, and my proposed tagging of the street/place
parts in OSM using this ordering:

A/ Standard single-street setup

https://www.openstreetmap.org/#map=19/52.41383/0.74970

W H Smith Ltd
7 King Street
Thetford
IP24 2AN

addr:housenumber = 7
addr:street = King Street

B/ Genuine two-street hierarchy

https://www.openstreetmap.org/#map=19/52.61765/1.19746

6 The Close
School Lane
Little Melton
Norwich
NR9 3AE

addr:housenumber = 6
addr:street = The Close
addr:parentstreet = School Lane

C/ Named site off a main road, with addresses numbered/named within
the site, e.g. a retail park

https://www.openstreetmap.org/#map=18/52.40556/0.72399

Currys
Unit 1
Forest Retail Park
London Road
Thetford
IP24 3QL

addr:housenumber = 1
addr:place = Forest Retail Park
addr:parentstreet = London Road

D/ Named ste with named streets within it e.g. a larger retail park

https://www.openstreetmap.org/#map=17/52.03308/1.20414

Furniture Village
3 James Bennett Avenue
Futura Park
Ipswich
IP3 9SR

addr:housenumber = 3
addr:street = James Bennett Avenue
addr:place = Futura Park

E/ Name site off a main road also with named streets within it, e.g. a
large caravan park

https://www.openstreetmap.org/#map=17/51.82229/1.06501

1 Beech Way
Bentley Country Park
Flag Hill
Great Bentley
Colchester
CO7 8RF

addr:housenumber = 1
addr:street = Beech Way
addr:place = Bentley Country Park
addr:parentstreet = Flag Hill

My reasoning for needing all three tags, and the choice of ordering is
as follows. The above examples show we need to be able to capture
hierarchical street and site relationships in addresses. I don't think
we should use addr:place when the object is a street rather than a
place. Hence for case B we need two different street tags. (The
additional tag should be for the parent street rather than the child
street, so that the house number still belongs to addr:street. This is
safer in case the data consumer doesn't recognize the second street
tag.) Also, it would be better not to use addr:street (or
addr:parentstreet) for things that aren't streets. Hence addr:place is
needed for case C. We also need a way of having streets within or
outside a place, so need either two different street tags or two
different place tags. It's simpler to use the two different street
tags we already know we need. We then need to ensure the ordering is
such that addr:street and addr:parentstreet sit either side of
add:place. This defines the tags we need and their ordering. It's then
just a matter of picking the appropriate ones for any given address --
which works nicely for the examples above.

This scheme also has the advantage that if data users only pick up the
addr:street tag from the above, they will never assign a house name or
number to the wrong street. (e.g. if using addr:place and addr:street
in case C, and addr:place is not picked up by a data user, then the
number would potentially get associated with a different property on
the street. e.g. there could be a separate property "3, London Road"
in that example.) It also avoids having addr:street and addr:place
present together except for cases D and E, which are arguably quite
special. ( https://wiki.openstreetmap.org/wiki/Key:addr:place says "No
object should have addr:place=* and addr:street=* at the same time".)
If you wanted to avoid having both in case D too, you could keep
addr:street and use addr:locality for the retail park name instead.

One thing that isn't resolved by the above scheme though is what to do
with the (not uncommon) case of a named building or set of buildings
with various individual dwellings. This might include groups like
"Church Cottages" or "Orchard Terrace". If it was a named block of
flats or apartment complex, I think we'd probably all go for
addr:housename for the block/complex name and addr:unit for the
numbers within it. But here's a different specific example:

F/ Named collection (single building or group of buildings) made up of
individual numbered/named properties:

https://www.openstreetmap.org/#map=19/51.03946/-0.02748

5 Church Cottages
Church Lane
Horsted Keynes
Haywards Heath
RH17 7AY

Here the "Church Cottages" isn't really a place or a street. Under the
scheme above, we could possibly use either

addr:housenumber = 1
addr:place = Church Cottages
addr:parentstreet = Church Lane

or

addr:housenumber = 1
addr:street = Church Cottages
addr:parentstreet = Church Lane

But neither seems quite right to me. The other option would be
treating "Church Cottages" like a block of flats, and using:

addr:unit = 1
addr:housename = Church Cottages
addr:street = Church Lane

This doesn't quite seem right either, particularly if "Church
Cottages" is actually multiple semi-detatched houses, rather than a
single building. But on the plus side, any of these options would be
correctly parsed and result in a correctly ordered/rendered address
from our data. So perhaps it's not so important which method is used
for this case F.

So what do you think about the tagging of cases A-E, and what about
the different options for case F?

Best wishes,

Robert.

-- 
Robert Whittaker

_______________________________________________
Talk-GB mailing list
Talk-GB at openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-gb/attachments/20211221/ec1d26be/attachment-0001.htm>


More information about the Talk-GB mailing list