[Talk-GB] OSM UK address project: tags

[Nick]

A document I just found is quite helpful 
https://www.hertsmere.gov.uk/Documents/02-Business/Street-Naming--Numbering/BS7666-Standards-Guide.pdf. 


I was also wondering if USRN can be used from open data sources?

On 21/12/2021 19:45, Nick wrote:
> Just wondering if BS7666 is worth a look as there is a schema for it?
>
> On 21/12/2021 19:26, Robert Whittaker (OSM lists) 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.
>>
>
> _______________________________________________
> Talk-GB mailing list
> Talk-GB at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>