|Feature : Addresses|
|Used to provide address information for the building or facility.|
Address information can be added to OpenStreetMap using a variety of methods, such as adding a simple node containing an address, adding address information to a building, site or other area, or alternatively to an entrance node for the building or site.
- 1 How to map addresses
- 2 Country specific rules and sources
- 3 Maps and quality assurance tools
- 4 See also
How to map addresses
- isolated nodes
- nodes that are parts of building polygons ( = entrance=*s )
- building=* polygons
- on polygons representing the perimeter of the site.
Historically, this approach originates from the Karlsruhe Schema.
Usually address informations doesn't need to be duplicated, i.e. there should be only one addr:housenumber=* per street and house number (which would typically be placed on the building). Software can usually link adresses to other features by geographical proximity, and duplicated addresses are often flagged as errors by quality assurance tools. However, there is still some debate on that point (see for example Address information in POI *and* building? on help.openstreetmap.org). Also, the community in some countries has established their own rules.
Tags such as addr:country=*, addr:city=* and addr:postcode=* are often redundant as features inside administrative boundaries (when mapped) "inherit" their attributes as supported by software such as Nominatim or Photon.
As of July 2015, about 10% of house numbers are mapped using relations. The future of the associatedStreet relation is questioned by some mappers.
The street relation is used to link streets to all things related to it, including building and addresses. It can also be used as an alternative to the addr:street=* as well as other addr:* tags such as addr:city=*.
Buildings with multiple house numbers
- Create an address node for each housenumber and place each node somewhere on the building outline (or inside the building).
- If house numbers are associated with individual entrances, tag those numbers to entrance=* (old version - building=entrance) nodes.
- Separate the numbers by commas (e.g., 11,13,15).
- Specify the range (e.g. 10-95). Note that there is a risk of ambiguity between two meanings:
- When such a range is officially used for the entire house, this is the preferred method. In this case 10-95 is simply a label like any other. In this and other cases, house numbers officially contain a dash and are not meant to be treated as special.
- When such a range is meant to be interpreted as a list of addresses, use addr:interpolation=* (described below) to emphasise this. Some mappers will add a short "virtual" way which allows them to put addresses 10 and 95 on separate nodes as normal. Some mappers will specify the range 10-95 on a single object, where the addition of the addr:interpolation=* tag disambiguates it from the "simply a label" meaning, specifying that it is indeed to be treated as a range. Both approaches are used in practice and there is little consensus.
- Create separate connected polygons for buildings with different addresses. You may do this even if they share walls, but splitting a corner house diagonally is not widely accepted.
Multiple buildings for one housenumber
This often happens in farms, factories or schools. In that case, it's possible to add a perimeter to the site which contains the addr tags and other general tags such as the name. This makes sure you have less redundancy in your data. If the buildings cannot be contained in a single perimeter (for example, school with two buildings a block apart), use a multipolygon relation or site relation.
To name the buildings, use addr:housename=*.
As long as we don't have a node or building outline for each house(number) along a way, it's also possible to use automatic number interpolation. For that, draw a way connecting the existing house numbers and mark it with the type of interpolation as shown in the picture above. Additional tags such as addr:street=* are still added to the objects with the addr:housenumber=* tag, the interpolation way only gets the addr:interpolation=* tag.
For irregular missing house numbers (e.g., missing 13), two ways need to be drawn (e.g., 1-11 and 15-25). If there is a regular structure to the missing house numbers, for example, every other number is missing from a sequence (example for an odd way: 3401, 3405, 3409, etc.), use a numeric value with addr:interpolation=* to indicate the value to increment between house numbers. (Note: addr:interpolation=odd and addr:interpolation=even are just special cases of addr:interpolation=number, where number is 2, and the beginning node is odd or even, respectively.)
If there is a house number on a single node or single building polygon and that house number also appears as the result of an interpolation, software should handle this case gracefully and favour the individually tagged house number as the real position.
As seen in the example picture above, it's allowed to add nodes that do not have an integer value for their addr:housenumber=* tag somewhere in an odd/even/all interpolation (e.g., 12b). Those will be ignored for the interpolation. However, endpoints of the interpolation way always have to follow the given interpolation rule!
You can use the interpolation method alphabetic to interpolate the alphabetical characters in the house number. So if you have all the houses from 7a to 7f in a row, you can connect them by a way tagged with addr:interpolation=alphabetic. You can not mix alphabetic interpolation with other interpolation methods. There is a special case for the Latin character set in which the first entry in the sequence is a number, followed by the number plus the letter A. For example, the range 25-25F means that the houses are numbered 25, 25A, 25B … 25F.
Some mappers use addr:interpolation=* on a single object to indicate that its addr:housenumber=* is to be treated as a range rather than an atomic label (discussed above). There is not a consensus on whether this is appropriate.
Using Address Interpolation for partial surveys
To indicate the accuracy level of an interpolation, you can use the optional tag addr:inclusion=* to represent the data missing from a house number survey.
- Not all houses are yet present, but the endpoints of the street are surveyed.
- The endpoints of the street are unknown, but a possible range can be estimated.
- House numbers are missing or damaged beyond recognition, so the interval cannot be correct.
- Use of US TIGER data to indicate all possible addresses on a block; useful for routing to the nearest block where no survey has been done.
The optional tag addr:inclusion=* identifies the accuracy of the data.
- addr:inclusion=actual - Represents an accurate survey where calculating every house number from the address interpolation way results in an exact match with physical houses. This is the same meaning as omitting the addr:inclusion=* tag.
- addr:inclusion=estimate - The address interpolation way may contain numbers that don't actually physically exist for typical reasons of cases 1-3 above. A survey has been performed and geolocation calculations will be within several physical house spaces from the actual house.
- addr:inclusion=potential - The complete range of all possible address numbers on a block, although there may not physically be enough room on the block for that range of house numbers. Interpolation data from US TIGER is an example where geolocation would only be as near as one block.
Letters in house numbers (for example in Russia)
Russian addresses may have complex addr:housenumber=* values with letters, ex. 48А к2 с1  (means house number 48А, building 2, construction 1). In some cases, official addresses have only "корпус" (building) numbers, so addr:housenumber=* will start with letter "к".
Addresses without street names
Some building addresses do not contain a street name. For example, in small villages the address may be just the village name and the name or number of the house; on a small island the address may be the name of the island and the name of the building (for example this sports centre on Yelagin Island, St. Petersburg, Russia).
In some post-Soviet states, such as Turkmenistan, building addresses consist of the house number and the name of the administrative district of the city (and sometimes a subdistrict of the district) in which the house is located, such as the Parahat and Howdan neighborhoods of Ashgabat. In these cases the house numbers were assigned in the order the structures were built and thus bear no relation to the relative location of the buildings to each other.
In these cases no tag addr:street=* should be present. The key addr:place can be used instead of addr:street to indicate the part of the address that takes the place of the street name, such as the name of the village, subdivision, or island. In the case of buildings in a district and/or subdistrict, the tags addr:district=* and if applicable addr:subdistrict=* should be used to make the addresses searchable and routable.
Country specific rules and sources
The Flemish Agiv (Agentschap voor Geografische Informatie Vlaanderen) provided access to their address database. The database isn't used for a direct import, but its data can be compared with OSM data to find differences. See the documentation for more info.
The system is described on page Cs:WikiProjekt Česko/Systém adres(cs).
Czech government provides open data for house numbers. House numbers are updated approximately every month. For more information see Address_import_from_RUIAN.
According to the Danish Bekendtgørelse om vejnavne og adresser (English: Ordinance regarding street names and addresses) all BBR units (lots) will be appointed an address node. If a building exists on the BBR unit the address node should be placed at in the middle of the longest side of the building 3 meters from the wall closest to the main (named) access road.
All Danish address nodes are (since february 2009) imported from a central service operated by the Danish government and continuously checked and corrected against the same service. Foreign cartographers mapping in Denmark should be wary that the Danish community does not approve of merging the imported address nodes with buildings. When using the JOSM-plugin buildings_tools in Denmark, please ensure that it is not configured to automatically merge address nodes with buildings.
Even though bulk imports from public data in general has earlier led to bad results, the quality of the addresses from the Danish government is very high. The value of having millions of address nodes (with correct tags following the accepted addr scheme, even including several housenames - yup, this is also centralized information in Denmark) has led to a huge rise in the quality of the Danish data set, serving as a base for several QA tools (for finding "blank spots" on the map where addresses actually exist but no mapper has visited yet), e.g. matching addr:street up against name for nearby highways.
OSM France initiated an address centered project called "BANO" (Base d'Adresses Nationale Ouverte). This database is a composite from OSM address data, available opendata sets, cadastre data automatically extracted. The resulting composite dataset is available under ODbL and can be used to improve OSM addresses and street names. For more detail see WikiProject_France/WikiProject_Base_Adresses_Nationale_Ouverte_(BANO)(fr) and http://openstreetmap.fr/bano (fr).
Karlsruhe Schema is widely used (unsurprisingly, since it was invented in Germany). Interpolations are also used.
As of mid 2014, all Norwegian official addresses has been released to the public for free. The data is of very high quality. There are updates released regularly. We use a tool http://osm.beebeetle.com/addrnodeimportstatus.php (no) to keep track of progress and merging changes. All of them have been imported as nodes with addr:housenumber=*, addr:street=*, addr:postcode=* and addr:city=*. We follow the Danish pattern and do not merge the tags to building outlines. There is no need for interpolations, so we remove them as we go along. We also prefer to keep the data in the nodes alone, so associatedStreet relations are also unwanted and deleted as we go along. This is to ease later updates and have a very consistent dataset.
Instead of full address set for each object the addressing scheme is divided into two (actually three) levels as "objects" and "places".
1. Places are polygons with name and addr:country; optionally addr:region, addr:district and addr:subdistrict
2. Objects are any addressed entities like buildings, POIs etc.
Only addr:street and addr:housenumber are required, the rest (country, region) is inherited from surrounding place polygon.
3. If POI is placed inside building polygon then it inherits address from the building.
Maps and quality assurance tools
There are visualisations of address and building information available as an ITO Map layer and as a view within Geofabrik's OSM Inspector. These visualisations track building tags, and shows if any address/name data is present. OSM Inspector also provides checks on address interpolation ways. Coloured Streets is a JOSM mappaint style which is specialized on address data.
- qa.poole.ch (QA tool) — there is a layer that displays buildings with missing addr-tags and a layer that displays objects with addresses. See qa.poole.ch (QA tool) for details.
- Category:House numbering - software category
- For some background information about the initial proposal, please refer to Karlsruhe Schema
- The relations "street" and "associatedStreet" as alternative to addr:street=*
- The tag is_in=* as an alternative to addr:city=* and addr:country=*
- phone=* / contact:phone=*, fax=* / contact:fax=* and email=* / contact:email=*
- Approved proposal for additional addr subkeys (addr:unit=*/addr:floor=*/addr:door=*)
- A polygon (closed way or relation) defining a postal code area, tagged with boundary=postal_code
- AddrN is a proposed extension for the Karlsruhe Schema. It allows tagging multiple addresses for one building.
- Relation:street, a possible alternative to the associatedStreet relation