Addresses

Feature : Addresses

Description

Used to provide address information for a building, facility or any other object that has an address.

Group

Tags

Address information can be added to OpenStreetMap using a variety of methods. These include 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.

OpenStreetMap tagging provides support for various address schemes used across the world.

How to map

Addresses can be tagged with addr:housenumber=* and the other addr:* keys. Tags can be added to:

isolated nodes inside building=* polygons
building=* polygons
nodes that are parts of building polygons (entrances) or on the access to a property (e.g., on barrier=gate or barrier=entrance), used in places where addresses are assigned to entrances and accesses rather than to buildings)
on polygons representing the perimeter of the site (if addresses are assigned to buildings, this approach should be avoided)

Historically, this approach originates from the Karlsruhe Schema.

The Rapid Address Collection page outlines methods of collecting and mapping address data rapidly.

Usually, address information 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 typically link addresses 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=* are often redundant as features inside administrative boundaries (when mapped) "inherit" their attributes as supported by software such as Nominatim or Photon.

Main article: Mapping addresses as separate nodes or by adding to building polygons

Using relations

The associatedStreet relation provides a link between houses and streets. This can be used as an alternative to the addr:street=* tag.

As of February 2022, about 5% 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

Main article: Mapping addresses as separate nodes or by adding to building polygons

There is currently no global consensus on this. Here are some possibilities:

Create an address node for each housenumber and place each node somewhere on the building outline (or inside the building)
- in some cases there is a local consensus that this approach is preferable, for example in Poland
- (Don't then also give the building an address, else all the numbers will be duplicated.)
If house numbers are associated with individual entrances (or gates), tag those numbers to entrance=* (or barrier=gate) nodes.
Separate the numbers by commas (e.g., 11,13,15) or semicolon (e.g., 11;13;15).
- Currently, the comma version is more popular. While the default separator for multiple values in OSM is the semi-colon, the "Karlsruhe Schema" widely adopted for addresses mandates the use of a comma to separate house numbers.
- In a discussion on the tagging mailing list it was proposed to use a semi-colon instead. See [1][2].
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.
- Note that in some cases building or building complex has single address such as 3-5 that only looks like a housenumber range. As usual, do not convert such data blindly, without a verification.
In case of separate buildings mapped as one it is recommended to create separate connected polygons for separate buildings, each with own address.
Remember that there are also buildings which are a single building with one entrance and nevertheless have a "hyphenated " address, e.g. 4-5 Bonhill Street 157901333 157901333 and other buildings nearby. In this case, there aren't separate entrances to map. In some cases entire facility with multiple buildings has such address, such as hospital in Poland with address Wrocławska 1-3 Kraków.^[1]

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

Interpolation

If we don't know (or don't have time to find) every house number, we can use interpolation. This allows people and machines to guess where an address probably is, between two known points.

You need to know two house numbers, and the sequence pattern.

E.g., in a terrace of houses, perhaps you know that the first house is 15 The Road, the last is 27 The Road, and that this side of the road the house numbers are all odd.

Basic instructions

Create a node for the lowest-numbered address
Tag it with addr:street and addr:housenumber.
Do the same for the highest-numbered address
Draw a way from the lowest-numbered address node to the highest-numbered address node
Tag this with the correct interpolation tag (see Tag options, next section).

Tag options

The basic tag for the interpolation way is addr:interpolation=*

Common values for **`addr:interpolation=*`**
Value	Meaning
all	House numbers between the nodes are in strict numerical order.
odd	House numbers are in numerical order, odd numbers only.
even	House numbers are in numerical order, even numbers only.

Examples
Feature	Map link
Lowest-numbered address node	https://www.openstreetmap.org/node/401884984
Highest-numbered address node	https://www.openstreetmap.org/node/401884983
Interpolation way	https://www.openstreetmap.org/way/34609524

Note that the interpolation way has only one addr: tag, the addr:interpolation=* tag. It doesn't take addr:street=* , addr:city=*, or any other address information (but advanced users might set a second interpolation tag: see Using address interpolation for partial surveys).

More unusual cases

For irregular missing house numbers (e.g., missing 13), two ways need to be drawn (e.g., 1-11 and 15-25).
You can use alphabetic to interpolate alphabetical characters. 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.
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. (Here we would use addr:interpolation=4.)

addr:interpolation=odd and addr:interpolation=even are just special cases of addr:interpolation=number, where number is 2 (i.e. addr:interpolation=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! i.e. For addr:interpolation=even the addr:housenumber=* tag on the end nodes must be an even number.
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 (Addresses) (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 neighbourhoods 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.

Addresses without house numbers

In this case use the tag nohousenumber=yes and remove the tag addr:housenumber=* if exists like addr:housenumber=s/n (in this example "s/n" is means "sin número" in Spanish and "sem número" in Portuguese).

Country specific rules and sources

Australia

Main article: Australian features tagging guidelines

Belgium

Current practice is that addresses are put to the building polygon when the building only has a single address, and as nodes if a building has more than one address.

Brussels

URBIS numerical imagery is available out of the box in JOSM and iD. It shows the official outline of buildings, street names and housenumbers. It is the official reference to trace buildings and to identify addresses within the Brussels-Capital Region. The map is updated about 2 or 3 times a year.

Addresses are shown as floating numbers within the building, it is up to you to figure out the street associated with this housenumber. (Here is a way to get the official address: go to https://datastore.brussels/web/map and load the following layer: Urbis Services > Address Points, then query a housenumber, scroll down the Address Point text box and read the values under pn_name_fre and pn_name_dut.) The source data comes from urbanisme/stedenbouw departments of each of the 19 municipalities. Some are faster than others to add new buildings.

Like any government source, it might be outdated, or sometimes plainly wrong. It is a good idea to fill the "note" tag on addresses that significantly differ from what is found on the URBIS map, e.g. if the entrance door is in another building. Also, large residential buildings or office buildings often have additional housenumbers on the URBIS map that do not exist at all. Do not delete them, keep the nodes and tag them as not:addr:housenumber=* to prevent armchair mappers from adding them again.

You should stick to addr:street=* and addr:housenumber=* for addresses. Country name, city and postcodes are automatically generated through existing areas. This is especially necessary in Brussels because most people are unaware of the many discrepancies between municipalities’ borders and postal codes and would otherwise add incorrect data.

Flanders

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.

Bulgaria

Bulgarian addresses can be of 2 types: the usual addr:street=* + addr:housenumber=* system, and one where apartment blocks get a block number preceded by "бл." (блок=block) + the name of the neighbourhood (which goes into addr:place=*). So бл.474, ж.к. Младост 4 is tagged with addr:housenumber=бл.474 and addr:place=ж.к. Младост 4. addr:housenumber=* thus often contains the string "бл." followed by numbers (optionally separated by a space). Some blocks have addresses according to both systems, where the block number address should go on the building outline and the street+number address on a node inside the building.

Czechia

Czechia uses its own system for mapping addresses as the use of addr:housenumber=* is not sufficient. Additionally we use these tags:

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.

Denmark

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

France

OSM France initiated an address centred 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 BANO – La Base Adresses Nationale Ouverte, par OpenStreetMap France(fr) .

Germany

Karlsruhe Schema is widely used (unsurprisingly, since it was invented in Germany). Interpolations are also used.

Italy

Italy does not have house numbers. The numero civico identifies the entrance that directly or indirectly leads from the highway, square, ... to building units or to unbuilt and fenced areas (beach resort, ...). As a result, properties (buildings, ...) and numeri civici are not 1:1 - a property can have many numeri civici and many properties can share the numero civico.

The community-approved convention is documented here. A short summary for non-locals:

Tag address information on the entrance node with addr:*. The numero civico goes in addr:housenumber=*.
Address information and addr:* can only go on entrance nodes.

In practice:

The usual case is that an entrance=yes/no, barrier=gate, ... also has addr:*. Sometimes a shop window or other former or potential entrance can also have a numero civico.
For amenities, shops and other POIs, the Bremen schema or extended Karlsruhe schema is popular in the Italian community to comply with the ban on addr:* while tagging in the form of contact information with contact:*.

In historic context it is also not unusual to have building entrances with house numbers on the first (and other upper or lower) building level(s). In these cases you can add level=1(etc.) to make the situation explicit. For places without assigned house numbers (called snc or senza numero civico in Italian) you should use nohousenumber=yes and keep addr:housenumber=* empty.

Latvia

Since January 2022, all official addresses in the State Address Register have been released as open data and updated every working day. Since June 2022, automated updates of addresses in OSM are being performed approximately every month by user latvia-bot using code published at GitHub. See bot's wiki page for detailed information.

Almost all address tags are managed by the bot and any edits of these tags by users are discouraged during update. Exceptions are keys addr:unit, addr:door, addr:flats and addr:floor. For these, user input is still welcomed as these data are not obtainable from the State Address Register. Don't use relation associatedStreet and tags indicating that there is no address (noaddress and nohousenumber).

Addresses are assigned either to building polygons (ways or relations) or address points (nodes) if there is no building polygon in OSM or it doesn't contain address point from the State Address register, or majority of the polygon don't overlap the one from the State Immovable Property Cadastre Information System containing an address point (also published as open data and used by the bot). Addresses are also assigned to all tags listed in tags_4_addresses.csv if there is a spatial match. In case tag is not included and you think it should be, create an issue on GitHub.

New Zealand

Street Addresses in New Zealand have been imported into OSM from government data, and the data is regularly conflated. See Import/New Zealand Street Addresses (2021) for more information.

Rural addresses

From Rural Address Property Identification:

The Rural Addressing scheme was adopted in Australian/New Zealand Standard 4819:2003 Geographic Information – Rural and urban addressing in 2003. It is based on RAPID, an acronym for Rural Address Property IDentification, a scheme first instituted in New Zealand in 1999^[2] to assist emergency services in identifying and locating rural properties.

An example address of 1536 Longley Road can easily be found by dividing by 100. This tells anyone looking for the property, that it is 15.36 km from the start of Longley Road. An emergency crew can set the vehicle trip meter at the beginning of the road and know they do not need to waste time checking for letterbox numbers until the trip meter gets close to the rapid number they are looking for.

Any rural property can have a number, and some have multiple numbers for different entrance ways off the road. This helps when a visitor needs to access stockyards or other parts of a rural property.

Example: house numbers along Mountain Road are determined based on the distance from the start of the road (310500686 310500686)

Netherlands

Addresses and buildings in the Netherlands have been imported into OSM from government data, see BAGimport. The choice has been made to use a address node separate from the building. See NL:BAG for more background on the "Basic Records of Addresses and Buildings". Since the BAGimport name as agreed to be used on addresses with the addr:street tag can be different to the street name value on ways, the BAGimport name is recorded in the official_name tag on streets as for example Doctorandus F. Bijlweg versus Drs.F. Bijlweg,

There is a JOSM plugin to merge updates, see BAG-importverzoeken for a forum topic where you can ask someone to do that update.

Norway

As of mid 2014, all Norwegian official addresses has been released to the public for free. The data is of very high quality, with coordinates close to the main entrance of buildings. There are daily updates in the source. We use a tool addr2osm (GitHub) to update addresses on a monthly basis. All addresses are imported as separate nodes with addr:housenumber=*, addr:street=*, addr:postcode=* and addr:city=*. We follow the Danish method and do not merge the tags to building outlines. We prefer to keep the data in the nodes alone, so associatedStreet relations are not needed. 100% of public addresses in Norway are currently in OSM.

Pakistan

Addresses in Pakistan can be quite variable in their format, and it may not be easy to find a distinct address for many features. Pakistan is a predominantly rural country, and deliveries to small villages may not necessarily require an address to a specific building if the person taking an item to its destination knows where to find the intended recipient, or who to ask if not. Locations in urban centres are more likely to have specific assigned addresses, and can include any number of specifiers to narrow down a location.

See the Universal Postal Union document on the Pakistani addressing standard as a reference point for what may be included in an address where available.

The primary postal operator in Pakistan is Pakistan Post. You can find a listing of post offices and post codes on their website here: [3]. Major hub post offices in this listing are suffixed with "GPO" (General Post Office), and smaller post offices are each assigned to a hub.

Pakistan is divided into provinces and districts. The province can be tagged with addr:province=*, but it is not necessary if the district (addr:district=*, city, and/or postcode is specified. "Distt." is a common abbreviation for district in Pakistani addresses, though if tagged in OSM it should be unabbreviated as is convention. Districts are further divided into tehsils, which are in turn divided into union councils, but these are typically not included. addr:place=* may be necessary for addresses which involve a place name rather than a street name, or addr:full=* for addresses which are challenging to describe with the existing address tagging scheme. Addresses in larger cities such as Islamabad can be quite elaborate, and may include features such as a block number, which can be tagged with addr:block=*, or a sector number, which as of the time of writing (May 2022) does not have a single/standard tagging scheme. At the moment, the most common places sectors have been included in addresses in OSM are in addr:place=*, which is technically not correct as "places" are intended to be mutually exclusive to street names and sectors are typically supplemental to them, or included at the end of the street name itself. addr:sector=* (undocumented) has been used 3 times in Pakistan, but has been used in Guatemala ~2000 times. It is likely addr:sector=* is the clearest way to tag the sector number to avoid conflation with tags intended for other purposes, but feel free to contribute to the discussion on the talk page at Talk:Addresses#Addresses_with_sector_numbers if you have thoughts on how to approach these.

For more details regarding the idiosyncrasies of adding addresses in Pakistan and some real world examples of point of interest tagging, see: Addresses in Pakistan

Philippines

Main article: Philippines/Addressing

Russia

Modified Karlsruhe Schema with AddrN additions is widely used and supported by most software. [4]

Instead of full address set for each object the addressing scheme is divided into two (actually three) levels as "objects" and "places".

Places are polygons with name and addr:country; optionally addr:region, addr:district and addr:subdistrict.
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.
If POI is placed inside building polygon then it inherits address from the building.

Turkey

addr:street and addr:housenumber is enough on most cases (as the rest is mapped as polygons in many cities); however as the subdistrict and district boundaries might not be very accurate (especially if the neighbourhood and postal code boundaries are not mapped), it'd be better to add additional information if deemed necessary.

Note that the street names with slash (e.g., 1/1. Sokak) are separate street names from their main street (1. Sokak) and should be mapped with the slash. Those streets are formed after street numbering is done and therefore inherited their parent street's name and numbered starting from there, even though they don't have a direct link to it any more.

If the house number includes a number and/or letter separated with a slash, map addr:housenumber as such.

While parsing the address, please pay attention to the formatting. According to the handbook of postal service, it's formatted as:

Turkish address format
Saraç İshak Mahallesi İbrahim Paşa Yokuşu No: 13/A 34130 FATİH/İSTANBUL TÜRKİYE	`addr:neighbourhood=Saraç İshak Mahallesi` (optional) `addr:street=İbrahim Paşa Yokuşu` `addr:housenumber=13/A` `addr:postcode=34130` (optional) `addr:subdistrict=Fatih` (optional) `addr:district=İstanbul` (optional) `addr:country=TR` (optional)
Example: 6072311186 6072311186

The postal service also provides a spreadsheet with the postal code of neighbourhoods (the postal codes often includes between 1-10 neighbourhoods and corresponds to their administrative boundary).

United Kingdom

Main article: Addresses in the United Kingdom

United States

This electric substation does not receive mail, but its street address is prominently signposted anyways.

Like many parks, this city park has an address for navigational purposes only.

In the United States, both buildings and land parcels are generally considered to have addresses, whether or not they receive mail directly. Generally, addresses are tagged on buildings, but campuses and other large properties are often tagged with an address in addition to any feature tag. The address goes on the main building or buildings on a property; it is unnecessary to tag an outbuilding, such as a garage or toolshed, with an address unless it differs from the main building's address. Addresses are also tagged on points of interest when they're mapped separately from buildings.

On a property or in a building with multiple tenants, each unit may have its own unit number or it may have its own distinct house number. There is no consensus on how to represent secondary unit designators. As of June 2021, it is far more common to omit the designator and only include the identifier (typically a letter or number) in addr:unit=*.

Data consumers should be careful when parsing the addr:housenumber=* and addr:unit=* tags: in Queens, New York, a standard house number contains a hyphen. Similarly, there are many retail centres and office parks in which each unit number contains a hyphen.

If a property abuts multiple streets, there is no guarantee that the addr:street=* can be correctly inferred from the relative position of the building, entrance, driveway, or mailbox. For example, this house is associated with West Loveland Avenue, even though it is much closer to Osage Drive and its driveway connects to Osage Drive. This house is associated with a different street than the house across the street, even though both houses face the same street and their mailboxes and entrances are accessed from the same street.

Postal cities and ZIP codes do not necessarily correspond to administrative boundaries (and even cross state boundaries [5]), so there are many cases in which tagging addr:city=*, addr:state=*, and addr:postcode=* is not only helpful but necessary to avoid misleading geocoder behaviour. A non-trivial number of ZIP+4 codes have been tagged in OSM, so data consumers should not assume that two distinct addr:postcode=* values necessarily mean two different ZIP codes; it would be necessary to trim the four-digit extension before making that comparison.

Ukraine

Main article: Addresses in Ukraine

Maps and quality assurance tools

There are several websites or tools that can help with checking the quality of address data in OpenStreetMap:

The Nominatim Data Analyser is a QA tool used to scan the Nominatim database and extract suspect data from it. Checks include addresses where the addr:street tag differs from the name of the street that Nominatim has assigned to the address, and use of addr:street with addr:place (an invalid tag combination).
Geofabrik's OSM Inspector includes visualisations of address and building information. These visualisations track building tags, and shows if any address/name data is present. OSM Inspector also provides checks on address interpolation ways.
qa.poole.ch (QA tool) includes a layer that displays buildings with missing addr:* tags and a layer that displays objects with addresses.
Coloured Streets is a JOSM mappaint style which is specialized on address data.
There are always various ongoing MapRoulette Challenges that ask mappers to help fix address issues.

External links

https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/

Notes and references

[1] ttps://5wszk.com.pl/kontakt

[2] “Towards an international address standard”. 2008.

[1]

[2]

Addresses

Contents