Addresses in the United Kingdom

There are many address tags that are documented for use in OpenStreetMap but, as address schemas differ from country to country, not all are suitable for use within the United Kingdom. This page aims to describe how best to map addresses in the UK. The addr:substreet, addr:street & addr:parentstreet section of this page shows that address tags in the UK are unfortunately not straightforward.

OSM UK address editor

Adding a new address to OpenStreetMap.

In 2021 OSM UK secured funding to develop an address editor that makes it easier to collect address data. A beta release went live in early 2022 and can be accessed here.

The address editor makes use of openly licensed datasets in order to predict where an addressable point is. To do this we take OS generalised buildings and land ownership (Cadastral) parcels. The land parcels are used to split the generalised buildings (e.g split semi-detached houses into their two parts) and the centre of these split buildings become our predicted locations for addresses. These are then compared to the existing data in OpenStreetMap. We check for cases where the point falls within a building way in OSM, and when OSM already has an address within the Cadastral parcel. All of this is then presented in the user interface (we are using MapComplete as it works across desktop and mobile). Contributors can then add the address following a ground survey.

As one of the key aims for this new editor is to attract new mappers to OpenStreetMap, we wanted to keep it simple as possible. This meant picking a method for when we need to represent a parent+child street/locality/thoroughfare. Following a discussion on the talk-GB mailing list we decided to use the feature agnostic addr:substreet tag to record child elements. Asking for users to decide between feature specific child tags would have added extra complexity and bought little benefit.

The editor is based on MapComplete. For the technically minded, the processed openly licenced data we described above can also be viewed and accessed via a set of tiled layers.

Address tags

This table lists keys in the addr:* namespace and guidance appropriate for their use when mapping in the UK. The ordering is the order in which the tag values should be listed as part of a full address. Suitable logic for taking the address tags and converting them to an address that you can print on an envelope is set out in the Tags to envelope section below.

Tag	Guidance
addr:unit OR addr:flats	If a named building or large complex is split into sub-parts then you need to use one of these tags. This puts that sub-part before the building name when the address is written out on an envelope. The choice of tag depends on whether you are recording a single address of multiple addresses. For more info see the addr:housenumber, addr:unit and addr:flats section below. Single address: Use addr:unit to record the number, letter, or name of a single unit or flat that exists within a larger complex. If a ground survey identifies a "Flat 1" then the tag should be addr:unit=Flat 1, i.e. it should include the word Flat. Similarly if a ground survey identifies a "Unit B" then use addr:unit=Unit B as the tag. Multiple addresses: To record a list of multiple flat numbers accessible in a building or behind a door use the addr:flats tag.
addr:housename	Used to record the house name of delivery points that have a name instead of, or as well as, a number. For UK addresses the house name will appear before any house number when the address is written out on an envelope (and after any unit number).
addr:housenumber	Used to record the house number of a delivery point. If the number needs to appear before the house name on a UK addressed envelope, then use addr:unit instead.
addr:street OR addr:substreet	To decide which tag you should use you need to consider how delivery points (e.g. house numbers) are first grouped: Grouped by a street: Use addr:street when delivery points (e.g. house numbers) are grouped by a street. A way with highway=* or a square with place=square with the same name should be found nearby. You can use the OSM Inspector quality assurance tool to check that the delivery point has been properly associated with the OSMhighway=* by looking for the Connection lines in the quality assurance tool. In some cases the delivery points may then be later grouped by another street. We call this secondary grouping a "parent street" and use the addr:parentstreet tag (see below). Grouped by any other feature (including if later grouped by a parent street): Use addr:substreet when delivery points are first grouped by some feature which is not a street. For example “West Business Park”, “South Retail Park”, “Castle Mews”, “The Cross”, “University Park”, “Church Cottages”. In some cases the delivery points may then be later grouped by a street. We call this secondary grouping a "parent street" and use the addr:parentstreet tag (see below). Note that addr:substreet can be used for non-street features where a parent street name is not part of the address. Note: Some OpenStreetMap members have suggested using addr:place instead of addr:substreet. This would mean adding UK examples to the description of addr:place and adjusting it's description such that it can be used when a parent street appears in the address. Unfortunately the addr:place tag is frequently misused and therefore data users would struggle to rely on addr:place for high quality data. For more info, please see the addr:place section below.
addr:parentstreet	This tag is not used globally but it is required in the UK where a building has two street names in its address, or some other parent+child type relationship. Use addr:parentstreet for the "parent" (more senior / larger / more important) street and use addr:street or addr:substreet for the "child" (junior / smaller / less important) feature. As noted above, if the child feature is a street you can use addr:street but if the child feature is not a street, then use addr:substreet instead. For more info, please see the addr:substreet, addr:street & addr:parentstreet section below.
Tags above this row relate to the parts of an address that position the location within a neighbourhood and require a ground survey, the tags below then set out which area (addr:suburb) and settlement that the location is within. These tags often can be added without a ground survey and are therefore not part of the OSM UK proposed address editing software/app/website.
addr:suburb	The addr:suburb tag should be used in cases where the address includes a sub area to the major location/postal town. This sub area could be a hamlet, village, town or an area of within a larger settlement. Sub areas can also be places that local people would easily recognise as areas in an wider urban environment such as “West Business Park”, “South Retail Park”, “University Park”. Note: This tag is often misunderstood as we apply our own perception as to what a "suburb" is and choose to incorrectly use other tags such as addr:place, addr:locality or addr:village instead. Just like with addr:city below, the word "suburb" in addr:suburb should also not be interpreted based on our view of what a suburb is or isn't. Instead this tag is just part of a hierarcy where addr:suburb is the smaller element and addr:city is the larger.
[Undefined mid-hierarcy tag]	Three tags (addr:hamlet, addr:village and addr:town) have been used by mappers in the UK but in most cases this is probably an error. To record the name of the major location (i.e. the "postal town") in an address use the addr:city tag even if this location is not a city. This is because addr:city is the globally accepted tag to use and the word "city" in addr:city has nothing to do with the word "city" in place=city. If you need a second tag to record a minor location, then use addr:suburb. In some rare instances in the UK, it may be take a third tag to record all the components of the address location. While we have globally agreed tags for the major (addr:city) and minor (addr:suburb) components, there is no globally agreed tag for the middle of the three. Until such a tag is agreed, then any of addr:hamlet, addr:village and addr:town seem suitable. Of these, addr:village has been used the most.
addr:city	The globally accepted tag for recording the largest settlement in an address. As such you should use addr:city to record the name of the major location (i.e. the "postal town") as given in postal addresses even if this location is not a city as the word "city" in addr:city has nothing to do with the word "city" in place=city.
addr:postcode	Used to record the UK postal code.

There are also several tags that have been used in the UK which shouldn't have been. These include addr:locality, addr:subdistrict and addr:site. See the tags to avoid section below. Please note that addr:district (Local Authority area), addr:county and addr:country have also been added to the tags to avoid section. This is because all three can be automatically determined using the admin boundaries in OpenStreetMap and, in the case of addr:district and addr:county no longer form part of widely used addresses since the abolition of the Postal Counties (wikipedia).

Examples

Some examples to help clarify the rules:

Full address	Tags	Notes
1 Rightons Court High Street EVESHAM WR11 4DD	addr:housenumber=1 addr:street=Rightons Court addr:parentstreet=High Street addr:city=Evesham addr:postcode=WR11 4DD	Rightons Court is a "real" road, with a street sign. It just so happens that the Royal Mail postal address also includes "High Street". In OSM there is a highway=residential with name=Rightons Court. Evesham is the largest settlement in the address (and the "postal town") so it is declared using addr:city even though it is not a city.
1 Essex Court Lyttelton Road Warwick	addr:unit=1addr:housename=Essex Court addr:street=Lyttelton Road addr:city=Warwick	Essex Court is a building with flats in it that is slightly offset back from Lyttelton road. Whilst there are a few parking spaces, you wouldn't say this comprises a "real" road (and there is no highway=* feature in OSM with this name) and hence we put Essex Court in the addr:housename tag and Lyttelton Road in the addr:street tag. Warwick goes in addr:city even though it is not a city as it is the largest settlement in the address.

Address validation tools

Global

A list of global validation tools can be found at Addresses#Maps and quality assurance tools. Note that these may not capture all aspects of the UK-specific tagging set out on this page.

UK specific

• OSM UK Address envelopes map (uses the strict method to show address envelopes).
• Robert Whittaker's OpenStreetMap Stuff site has a section on addresses (largely compaitble with this page with some minor inconsistencies such as inclusion of addr:locality).

Further reading

Tags to avoid

Widely unaccepted

The following table sets out tags that are widely unaccepted by the OpenStreetMap community in the UK. You should stop using these tags and use the suggested alternative (where appropriate).

Tag to avoid	Reason to avoid this tag
addr:locality	This tag is not part of the set of tags described on address tags wiki page. To avoid further complicating the address mapping in the UK (and globally) it is best to avoid this undefined tag. Note that whilst this tag is not defined in the wiki, place=locality tag “is used to name an unpopulated location for which there is no extant feature to which the tag could be associated”. Globally, addr:locality is little used outside the UK (see image below) and use within the UK is clustered suggesting only a few mappers have previously used this tag. → Use addr:suburb, addr:village (or similar from the settlement hierarchy) instead.
addr:site	This tag was incredibly rare (less than 40 uses) and is not part of the set of tags described on address tags wiki page. Avoid this undefined tag. → Use addr:substreet or addr:suburb instead (depending on context).
addr:subdistrict	Avoid as the tag should be for administrative regions which are not present in the UK. → Use addr:suburb for sub areas of a settlement.
addr:district	The tag is intended for recording the district (wikipedia), that is Local Authorities, in an address. The tag is not needed in the UK as it can be automatically determined from the admin boundaries and it doesn't form a part of a typical delivery address since the abolition of the Postal Counties (wikipedia).
addr:county	The tag is intended for recording the county in an address. The tag is not needed in the UK as it can be automatically determined from the admin boundaries and it doesn't form a part of a typical delivery address since the abolition of the Postal Counties (wikipedia).
addr:province	Avoid in the UK as the UK does not have provinces! Use addr:district for tagging the local authority, but even that is not needed as noted above.
addr:state	Avoid in the UK as the UK does not have states! Use addr:district for tagging the local authority, but even that is not needed as noted above.
addr:country	This tag not needed as it can be automatically determined from the admin boundaries.

Further proposals

This second table sets out additional tags which have been proposed as tags to avoid.

Tag to (possibly) avoid	Reason to (possibly) avoid this tag
addr:terrace	This is similar to addr:substreet in that it is used when delivery points are grouped by some feature before, or instead of, a street. However unlike with addr:substreet which is feature agnostic, addr:terrace can only be used when the delivery points are grouped by a named terrace building (e.g. "Caroline Buildings"). Some members of the UK OpenStreetMap community have suggested avoiding this tag and instead use the (feature agnostic) addr:substreet tag if a child element is needed in an address. By avoiding this tag we minimise the number of new UK specific tags that are introduced to the addr:* namespace. If mappers do continue to use the addr:terrace tag, then if both addr:substreet and addr:terrace are added to the same OpenStreetMap object then the value in addr:substreet will be used when producing an address that can be written on an envelope.
addr:hamlet, addr:village, addr:town	These tags have probably been incorrectly used due to mappers misunderstanding the globally accepted use of the addr:city tag. You should use addr:city to record the name of the major location (i.e. the "postal town") as given in postal addresses even if this location is not a city as the word "city" in addr:city has nothing to do with the word "city" in place=city. Some mappers have therefore suggested avoiding these three tags completely.

associatedStreet relations

This is a relation rather than a tag on a node or way. The associatedStreet relations have been used by some mappers as an alternative to addr:* tags however this method of mapping addresses is much less popular than addr:* and usage (as a percentage of mapped addresses) has been falling since at least 2015. A discussion on talk-gb in May 2022 showed that the popularity has also fallen in the UK with a number of mappers who have previously used this relation noting that they are now going back and removing them from their earlier edits. It is therefore a mapping method that should be avoided.

Tags to envelope

This section sets out how the address tags should be processed to produce an addressed envelope.

Strict method

The OSM UK envelopes map uses the strict method to show OpenStreetMap data as it would appear printed on an envelope.

The strict method is designed to show where tags have been incorrectly used (either a tag is used for the wrong purpose or a non-standard addr:* tag has been used). It is the method used on the OSM UK envelopes map.

Rules for taking OpenStreetMap tags and converting them to the address lines written on an envelope are:

1. Tag pre-processing steps (outside OSM):
   1. If addr:place exists and is different to addr:substreet then:
      1. if addr:substreet is null set addr:substreet equal to addr:place;
      2. else set addr:substreet equal to addr:place + " " + addr:substreet
2. Writing the address as appears on an envelope:
   1. Recipient's name goes on the first line (not in OSM database so we skip this line)
   2. Next print the Premise and Thoroughfare elements:
      1. On the next line, print “Sub-part” addr:unit and “House / Building name” addr:housename (separated by a space). If either are missing, just skip that but print the other part (e.g. show just “House / Building name” if no “sub-part” present.)
      2. On the next line, print “Number” addr:housenumber and “Sub-street” addr:substreet (separated by a space). If “Sub-street” does not exist, then print “Number” addr:housenumber and “Street name” addr:street instead (separated by a space). If “Number” addr:housenumber is missing, skip but print the other part.
      3. On the next line, print “Parent street” addr:parentstreet.
   3. Next print the Locality elements:
      1. Print lines with one item per line in the following order, skipping any missing tags or any repeat occurrences of a previously used tag value. Order is addr:suburb, addr:city
   4. Finally print the postcode and (if required) country elements:
      1. On the next line, print addr:postcode
      2. On the last line, print addr:country

Note that many mappers decide to stop at Premise and Thoroughfare elements, as such OpenStreetMap often does not include the Locality elements tags. These can be derived from other data within OpenStreetMap or outside of OpenStreetMap.

Forgiving method

The forgiving method is designed to cope with the most common forms of incorrect use of the addr:* tags. It also introduces a wider range of tags. Rules for taking OpenStreetMap tags and converting them to the address lines written on an envelope are:

1. Tag pre-processing steps (outside OSM):
   1. If addr:substreet is null, then set addr:substreet equal to addr:terrace
   2. If addr:substreet is equal to addr:street then set addr:street equal to null.
   3. If addr:parentstreet is equal to addr:street then set addr:street equal to null.
2. Writing the address as appears on an envelope:
   1. Recipient's name goes on the first line (not in OSM database so we skip this line)
   2. Next print the Premise and Thoroughfare elements:
      1. On the next line, print “Sub-part” addr:unit and “House / Building name” addr:housename (separated by a space). If either are missing, just skip that but print the other part (e.g. show just “House / Building name” if no “sub-part” present.
      2. On the next line, print “Number” addr:housenumber and “Sub-street” addr:substreet (separated by a space). If “Sub-street” does not exist, then print “Number” addr:housenumber and “Street name” addr:street instead (separated by a space). If “Number” addr:housenumber is missing, skip but print the other part.
      3. On the next line, print “Streetname” addr:street (unless this has already been printed in previous step)
      4. On the next line, print “Parent street” addr:parentstreet.
   3. Next print the Locality elements:
      1. Print lines with one item per line in the following order, skipping any missing tags or any repeat occurrences of a previously used tag value. Order is addr:place, addr:suburb, addr:hamlet, addr:village, addr:town, addr:city
   4. Finally print the postcode and (if required) country elements:
      1. On the next line, print addr:postcode
      2. On the last line, print addr:country

Note that many mappers decide to stop at Premise and Thoroughfare elements, as such OpenStreetMap often does not include the Locality elements tags. These can be derived from other data within OpenStreetMap or outside of OpenStreetMap.

addr:housenumber, addr:unit and addr:flats

When to use addr:housenumber?

This will be the tag that you use the most for recording the number of a delivery address. When combined with a street name, the number and street name will appear on the same line on an addressed envelope. Some properties have both a name and a number. In those cases the name (recorded in addr:housename) will appear above the number on an addressed envelope. An example of this are shown below with square bracket annotations:

Rose Cottage, [addr:housename]
12 High Street [addr:housenumber and addr:street]

If both addr:housenumber and addr:housename are present, they refer to the same property/building. In particular, addr:housenumber does not represent a sub-unit of addr:housename. When writing out the full address in the UK, addr:housename is written before addr:housenumber.

When to use addr:unit?

This is used when the number, letter or name of a delivery point exists within a larger (building) complex, the name of which also appears on the address before the street name. A building comprising multiple flats is a typical example. Essex Court on Lyttelton Road in Warwick is one such case of this. As shown in the images Essex Court is a building with flats in it that is slightly offset back from Lyttelton road. Whilst there are a few parking spaces, you wouldn't say this comprises a street and hence we put Essex Court in the addr:housename tag and Lyttelton Road in the addr:street tag.

1 Essex Court, [addr:unit and addr:housename]
Lyttelton Road, [addr:street]
Warwick [addr:city]

• 

  Essex Court, Warwick (street image)

• 

  Essex Court Warwick UK (aerial image)

Expressed in terms of the tags: The addr:unit tag numbers sub-divisions of an addr:housenumber and/or addr:housename entity. For example a block of flats/apartment might

have a name and/or number on a street, and then have numbered flats within it. The name/number of the block goes in addr:housename/addr:housenumber and the individual dwelling numbers go in addr:unit.

Please note that addr:unit can be used for sub-units with numbers, letter or names. If a ground survey identifies a "Unit 1" then the tag should be addr:unit=Unit 1, i.e. it should include the word Unit.

When to use addr:flats?

The definition in the wiki is that "unit" is for a single address whilst "flats" is for multiple (e.g. 1-6). Whilst this is the documented position it is not widely followed:

• The fifth highest use of addr:flats is for a single number (1).
• Ranges are used in the addr:unit tag (assuming 1-3 is a range and not the name of a unit)
• It is inconsistent with the addr:housenumber tag (TagInfo UK shows this is used for both single and multiple address cases, the wiki notes it can be used).

If you come across cases where addr:flats has been used when it should have been addr:unit, or vice versa, please fix these tagging errors.

addr:substreet, addr:street & addr:parentstreet

Why we need something more than just addr:street

Most addresses in the UK are quite straightforward, comprising a house number and a street name followed by a settlement name and a postcode. A small minority are however quite complex and require parent and child components to fully describe the address. To better explain this it helps to introduce some terminology. The Royal Mail Programmers' Guide states that an address is made up of:

• premises elements;
• thoroughfare elements;
• locality elements; and
• a postcode.

Elm Court, Devises, UK

In most instances, a single street name is all that is included within the thoroughfare elements. However this is not always the case and therefore the thoroughfare elements can include a "thoroughfare" (i.e. a parent) and a "dependent thoroughfare" (i.e. a child). Two examples of this are shown below with square bracket annotations:

Co-operative House [Building/premise name],
Warwick Technology Park [Child],
Gallows Hill [Parent],
Warwick [Settlement name]

1 [House number] Elm Court [Child],
Byron Road [Parent],
Devises [Settlement]

So knowing that some addresses require parent & child type combination, what tags should we use?

Discussion of parent and child tag options

This parent & child combination appears to be somewhat unique to the UK and, prior to any guidance, has resulted in a range of tagging depending on who mapped the address and whether the child element was a street, a terraced building or some other feature. We found cases of the following parent and child combination:

• addr:terrace with addr:street (for when the child element was a terraced building itself with a name)
• addr:street with addr:parentstreet (for when both child and parent elements related to a named highway)
• addr:site with addr:street (uncommon but observed when the address was within an area, e.g. a train station, accessed from a main street)
• addr:place with addr:street (similar to addr:site with addr:street)

To bring some consistency and make it possible to record the parent & child relationship regardless of the feature type of the child, a December 2021 proposal was shared on the talk-gb mailing list to standardise on the addr:place with addr:street combination. Whilst the proposer felt that the use of addr:place was in keeping with it's description (roughly "used when addresses are not grouped by street but by some other object") a number of objections were raised, along with objections on further extensions to the other combinations. In summary objections were raised in regards to the following:

1. Using both the addr:place & addr:street tags on the same address as this is a misuse of the original intent of the addr:place tag.
2. Using addr:place as a child component as globally addr:place is assumed to come later in the address (frequently misused with, but after, addr:street as an address would appear on an envelope).
3. Using addr:street for child elements that are not street.
4. Using addr:terrace for child elements that are not terraced rows.

The discussion shone more light on the addr:place tag and it's existing misuse. For further information please see the dedicated section on addr:place.

Furthermore it was noted that many of the alternatives (terrace, parentstreet, site, etc) are feature specific and therefore require mappers to make subjective decisions. For example, if a terrace row has a path should you map this in OSM with the name and therefore use addr:street in the address or should addr:street only be used for vehicle roads? Also, in the case of the Elm Court address above, is that referring to the building or a land feature like a courtyard or a small patch of off-road parking?

Finally, some also commented on how tags might be misinterpreted by systems that only expect to see the globally used addr:* tags. For example, the address "1 Melrose Terrace, Acacia Avenue" tagged using addr:terrace and addr:street, would be misinterpreted as "1 Acacia Avenue" by any systems that are not expecting and do not read the addr:terrace tag. Using the addr:street with addr:parentstreet combination gets around this problem (although obviously any systems that miss out the addr:parentstreet tag also end up with incomplete addresses) however not all child elements are streets and it therefore not correct to use the addr:street in these instances.

Based on this discussion, the addr:substreet tag was proposed.

addr:substreet

To record child elements of an address that come before a (parent) street name in a way that overcomes the above concerns, a new universal tag is required. If the addr:housenumber tag is also used then this new tag should appear on the same line as the housenumber if written out on an envelope. To align with the term used in BS7666, addr:substreet was proposed for this new tag.

addr:substreet is defined as:

Used when delivery points are grouped by some feature before, or instead of, a street. For example “West Business Park”, “South Retail Park”, “Castle Mews”, “The Cross”, “University Park”, “Church Cottages”. Note that the use of “or instead of” in this description means that addr:substreet can be used for non-street features where a street name is not part of the address. That is, it can be used inplace of addr:place. Can also be used when a feature has two streets in it’s address. In this case, use addr:substreet for the one that appears first on an address line, and addr:parentstreet for the second.

Note that addr:substreet can be used for all child elements regardless of the feature type (e.g. terraced building, site, another street, etc) as "sub-" just means under, below, etc to the thing (street in this case) as in subsurface, submarine, substandard and so on. The key thing is that it is the element that would appear on a line on an envelope before you get to the street name (if one exists) and locality elements.

With the introduction of this tag it makes sense to stop using (and phase down) use of addr:place in the UK given how inconsistently it is used. Those who do wish to continue using it should read the addr:place section and the tags to envelope logic to ensure that they are using it properly. Similarly if people want to continue using a more feature specific tag for the child element (e.g. addr:terrace if the feature is a terrace) then they can continue to do so but when producing an address for an envelope, if both addr:substreet and addr:terrace exist then then value in addr:substreet will be used.

addr:parentstreet

This tag is not used globally but it is required in the UK where a delivery point is grouped by some feature before then being associated with a (parent) street. For example, when a delivery point has two street names in its address. Use addr:parentstreet for the "parent" (more senior / larger / more important) street. You should then pick a suitable tag for the "child" (junior / smaller / less important) feature. As noted above, addr:substreet is a good feature agnostic tag, but if the child feature is a street or terrace then addr:street and addr:terrace (respectively) are acceptable feature specific alternatives.

Note that we use addr:parentstreet to record the parent street rather than just using addr:street because addr:street may have been used to record the (child) street and addr:parentstreet is considered more "fail safe" for systems that do not process these UK specific tags.

addr:place

In the UK most cases of addr:place and addr:street being used together are incorrect and are cases of where addr:suburb should have been used instead of addr:place. You can browse the Nominatim QA to find examples and help clean these up.

This is poorly defined in the wiki. It carries multiple definitions depending on where you look:

1. This is part of an address which refers to the name of some territorial zone (usually a place=* like island, square or very small village) instead of a street (highway=*). Should not be used together with addr:street=*.
2. Used when addr:housenumber=* is not grouped per street and by other object, usually a settlement.
3. Part of address, which is not related to street, but to some territorial zone, linear object, node or some abstract object

In December 2021 it was suggested that this tag can be used along with addr:street to tag those UK addresses that include both a parent & child element. The subsequent discussion on the talk-gb mailing list concluded that this should not be done. It also helped to provide additional context on the addr:place tag:

• addr:place is meant to be used when the address does not reference a street at all. This is frequently seen in small villages in continental Europe which often don't have any street names at all.
• addr:place is often wrongly used as a drop-in replacement for addr:suburb.
• In the UK most cases of addr:place and addr:street being used together are incorrect and are cases of "should use addr:suburb instead of addr:place". You can browse the Nominatim QA to find examples.

To give a bit of historic background on the addr:place tag, when the first addresses were mapped in OSM we started out with two basic assumptions. First that most addresses are street addresses (i.e. a house number that refers to the closest street) and second that a postal address is usually the same as the geographic location. People were aware that there are exceptions, which is why there are many addr:* tags. Still, the assumption was that in 99% of the cases you can add a addr:housenumber and be done with it. To compute the address find the closest street, village centre, county etc geographically. The result of this decision was that you can't just map an address that doesn't contain a street by leaving out the addr:street tag. Because the absence of the tag is defined as "use the closest street instead". That's where the addr:place tag came in. It was invented to clearly signal the data consumer that "this address does not contain a street; do not include the closest street in the address, instead start the address with this place after the house number". That's why the addr:street and addr:place tags should not be on the same object. It's sending mixed messages.

In January 2022 some OpenStreetMap members suggested using addr:place instead of addr:substreet. That is, while addr:place+addr:street was not seen as suitable for child+parent relations, addr:place+addr:parentstreet is seen as suitable. Using addr:place as such would mean adding UK examples to the description of addr:place and adjusting it's description such that it can be used when a parent street appears in the address. Unfortunately this does not get around the fact that the addr:place tag is frequently misused and therefore data users would struggle to rely on addr:place for high quality data. Most uses of addr:place in the UK are incorrect and and are cases where addr:suburb should have been used instead of addr:place. To some degree these can be identified from the fact that a feature includes both the addr:place and addr:street tags; an invalid combination and flagged by the the Nominatim QA site. Those data users who feel more confident in being able to automatically identify these misuses, or whose use case is more forgiving of the misuse (e.g. geocoding) tend to prefer addr:place over addr:substreet. Data users who are less confident in automated cleanup process, or simply require a higher degree of certainty in their data (e.g. in the case of using addr:* tags to print an addressed envelope) prefer addr:substreet.

A recommendation was made to use addr:substreet and an addr:place cleanup process was initiated . Currently that clean up attempt has not made enough impact to significantly change the arguments in the addr:place vs addr:substreet debate.

Other schemas and standards

Links relating to the Royal Mail PAF address system. Note that the PAF is a Royal Mail product and should not be copied.

• https://ideal-postcodes.co.uk/guides/good-addressing-guidelines
• https://docs.ideal-postcodes.co.uk/docs/data/paf/
• Edition 7 of the PAF programmers' guide

BS7666 guidelines:

• https://www.agi.org.uk/bs-7666-guidelines/