[Talk-GB] OSM UK address project: tags

Tue Dec 21 19:45:12 UTC 2021

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