[Talk-GB] UK street addressing

Colin Smale colin.smale at xs4all.nl
Mon Dec 21 12:50:18 UTC 2020


On 2020-12-21 13:01, Alan Mackie wrote:

> I struggle with what to call the <BuildingName> in that example. 
> 
> A recent suggestion for named terraces was to use addr:street=<TerraceName> and addr:parentstreet=<StreetName>, but if the <HouseNumber> relates the whole building to to parentstreet, then reconstructing an address seems impossible. 
> 
> The closest existing tag seems to be add:housename=<BuildingName>, but I don't know if that stretches the definition too much.

That will cause problems if the constituent parts (flats, houses in a
terrace etc) have a "name" instead of a number. Royal Mail say that a
house number must be numeric, and anything else (like Rose Cottage, 7A,
3-7, 11/13 etc) should go in the house name field. The OSM Wiki allows
non-numeric values though for some cases. 

> On Mon, 21 Dec 2020 at 06:41, Peter Neale via Talk-GB <talk-gb at openstreetmap.org> wrote: 
> 
>> At the risk of throwing another edge case into the pot (and mixing metaphors), can I ask how I should tag our flat? 
>> 
>> The Post Office Official postcode checker renders it as: 
>> 
>> Flat <FlatNumber> 
>> <BuildingName> 
>> <HouseNumber> <Street Name> 
>> <POSTTOWN> 
>> <POSTCODE> 
>> 
>> where <HouseNumber> refers to the whole block and is common to all the flats. 
>> 
>> I cannot see what the Post Office is calling the various data fields, but I assume OSM would be happy with (taking elements from above)  
>> 
>> addr:housenumber=<HouseNumber> 
>> 
>> addr:street=<StreetName> 
>> addr:city=<POSTTOWN> 
>> addr:postcode=<POSTCODE> 
>> 
>> That just leaves me to deal with the "Flat" element. 
>> 
>> Consulting the Wiki, I THINK I can cover that with: 
>> 
>> add:flats=<FlatNumber>  (for one specific flat) 
>> 
>> ...or addr:flats=<FlatNumberRange> (for the whole block) 
>> 
>> However, I unsure whether to include the word "Flat" in the value field of "addr:flats=*", or not.  The Wiki page for Key:addr includes, as an example, "addr:flats=Suite 110A", which seems fine for a single living space unit.  It could be called "Flat 110A", "Suite 110A", "Apartment 110A", etc., so including the descriptor word could be useful to the data consumer.  However, the Wiki page for Key:addr:flats shows only numeric values.  
>> 
>> TagInfo shows 203.5k uses of "addr:flats", but only 38 uses of "addr:flats=*flat*" and 42 uses of "addr:flats=*suite*", again suggesting that only the unique value(s) (e.g. "1", "2", "13B", etc.)  are sufficiently used to warrant data consumers catering for them.  
>> 
>> So, should I omit the word "Flat", "Suite", "Apartment" etc., leaving the data consumer to guess (or to default to "Flat...")? 
>> 
>> Regards, 
>> Peter 
>> 
>> On Monday, 21 December 2020, 09:30:37 GMT, Robert Whittaker (OSM lists) <robert.whittaker+osm at gmail.com> wrote: 
>> 
>> Like it or not, in the UK addresses are defined by Royal Mail. They're
>> introduced the concept of a "postal town", and this is one of the few
>> common elements that each address must always have. Once you accept
>> that the Post Town is intended to be a nearby significant place (to
>> help with delivery routing and identifying the rough location of the
>> addressed property) rather than being a place that the address is
>> "in", then it's really no more of a fiction than the postcode. (The
>> village I grew up in had a GL postcode, despite it being in
>> Worcestershire. I've currently got an IP postcode, despite being in
>> Norfolk and closer to Norwich (NR) than Ipswich.)
>> 
>> On the basis that it's a required part of each address, I would
>> recommend that we do store the post town in OSM addresses. There are
>> significant advantages to storing it in a consistent way, and the best
>> existing tag to do this would be addr:city. (We wouldn't want to
>> invent a new tag (e.g. addr:posttown), since as a UK-only term that
>> will simply be ignored by most international data consumers.
>> 
>> We then have a possible hierarchy of named localities between the
>> street and the post town to record as part of the address. I would
>> suggest using appropriate values from the set {addr:hamlet,
>> addr:village, addr:town, addr:suburb}. (I don't see any other
>> alternatives to this.) Most of these key names already have a
>> reasonable number of uses in OSM (addr:town is the lowest, but that
>> still has 59k uses), so it seems that others are doing this too.
>> 
>> Regarding properties (e.g. on named terraces or sub-streets), where
>> there are two street names (Thoroughfare and Dependent Throughourfare
>> in Rail Mail terminology) then we need a second key to store the other
>> street name under. Certainly if there is an addr:housenumber or
>> addr:housename, I think we need to use addr:street for the
>> street/terrace name on which that name or number applies. Otherwise,
>> software that's unaware of the second key name will think it's house
>> number n on the main street not the sub-street. There are already
>> about 3.5k uses of addr:parentstreet in OSM, so I'd recommend using
>> that for the main street, and addr:street for the terrace or
>> sub-street name. If any data-users aren't aware of addr:parentstreet
>> it's not a major issue, since it will still pick up the correct
>> terrace/sub-street name, and the locality, which will probably be
>> enough to use as an address.
>> 
>> I would strongly argue against using addr2 in connection with
>> sub-streets, as it's not standardised, and is likely to not be picked
>> up by any software. There's an abondoned proposal at
>> https://wiki.openstreetmap.org/wiki/Proposed_features/addr2 [1], but that
>> was for the case of a single property on a street corner having two
>> formal addresses, one on each street, not for the case of two streets
>> in a hierarchy.
>> 
>> Robert.
>> 
>> On Sun, 20 Dec 2020 at 12:47, Dave Abbott <Dave.Abbott at pandaemonia.org> wrote:
>>> I am trying to make sure I tag addresses correctly. I am currently
>>> trying to understand how to map in my area.
>>> 
>>> The postal addresses are like:
>>> 
>>> 99 Postal Street
>>> Smalltown
>>> Largertown
>>> West Yorks XY9 7GY
>>> 
>>> Smalltown is geographically separate to Largertown, which however is the
>>> Postal Town. Omitting Smalltown from the address is probably correct
>>> postally-speaking, but local residents would object as Smalltown is seen
>>> as completely separate to other places under the same Postal Town.
>>> 
>>> Currently tagging as -
>>> addr:housenumber=99
>>> addr:street=Postal Street
>>> addr:city=Smalltown, Largertown
>>> 
>>> But I am pretty sure this is wrong.
>>> 
>>> There is a page at
>>> https://wiki.openstreetmap.org/wiki/User:Rjw62/UK_Address_Mapping [2]which
>>> mentions "suggested tags" but there is no evidence that this is in use.
>>> If correct I would be tagging as -
>>> 
>>> addr:housenumber=99
>>> addr:street=Postal Street
>>> addr:town=Smalltown
>>> addr:city=Largertown
>>> 
>>> Hoping someone can advise me as to the correct way to tag for the UK...
>>> 
>>> Dave Abbott  (OSM user DaveyPorcy)
>>> 
>>> 
>>> _______________________________________________
>>> Talk-GB mailing list
>>> Talk-GB at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-gb
>> 
>> -- 
>> Robert Whittaker 
>> 
>> _______________________________________________
>> Talk-GB mailing list
>> Talk-GB at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb _______________________________________________
>> Talk-GB mailing list
>> Talk-GB at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
> 
> _______________________________________________
> Talk-GB mailing list
> Talk-GB at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
 

Links:
------
[1] https://wiki.openstreetmap.org/wiki/Proposed_features/addr2
[2] https://wiki.openstreetmap.org/wiki/User:Rjw62/UK_Address_Mapping
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-gb/attachments/20201221/6e209732/attachment-0001.htm>


More information about the Talk-GB mailing list