Proposal:Alternate addresses

Alternate addresses
Proposal status:	Proposed (under way)
Proposed by:	Joel Koen
Draft started:	2026-06-29
RFC start:	2026-07-14

Problem Statement

This proposal aims to provide a way to directly associate an object with multiple addresses.

Currently, the generally accepted way to tag objects with multiple addresses is using multiple separate address nodes. While this practice is flexible and works reasonably well in routing applications, it can be undesirable for a few reasons:

• by tagging addresses as separate nodes, addresses are no longer meaningfully associated with a specific object, and it becomes unclear what address nodes actually refer to other than a specific location.
• separating multiple addresses that refer to a single feature is against one of OSM's best practices: One feature, one OSM element
• it is not possible to tag one of the address nodes as a "primary" address, and the others as "alternative".
  • this means that multiple less-important addresses are rendered individually, which adds clutter to the map and in most contexts is unnecessary.
  • when addresses are too close together, it's not possible to prioritise rendering a specific address over others. An alternative address may be shown to the user instead of a primary address.

Proposal

This proposal extends the addr:*=* namespace to support tagging additional addresses on the same object in the form of addr:#:*=*. An object with multiple addresses must always have a primary address, which is used for rendering and reverse geocoding. Alternative addresses are then tagged using the numbered syntax, which software can make use of in search results in order to route to the same object.

For a simple example, to tag a building that is on the corner of a block that has valid addresses for both adjacent streets:

addr:housenumber=12
addr:street=Oak Street
addr:2:housenumber=34
addr:2:street=Maple Street

Rationale

Previously, Proposal:AddrN (2015) proposed using addr2:*=* to tag multiple addresses, however this proposal did not go further than RFC. It has gathered 21k+ uses [1], 13k of which are in Russia [2], but has no support from popular software.

This proposal aims to improve upon AddrN's numbered suffix syntax, which could be considered non-standard when compared to modern practices, as well as provide clearer examples of why multiple addresses are necessary, as such addresses are somewhat region specific and can be confusing to other mappers.

No inheritance

Additional addresses are completely separate from the tagged primary address, and do not inherit any attributes as part of this proposal.

Common attributes such as addr:suburb=*, addr:city=*, addr:postcode=* and addr:state=* can already be inherited from place, administrative and postal code boundaries. Nominatim already makes use of these boundaries, and can be viewed under the address section of an object's details page on Nominatim. However, support for this can differ between regions, depending on whether accurate data for these boundaries is available or if these attributes even fit into neat boundaries.

This proposal does not suggest that having some kind of inheritance for alternate addresses would be a bad thing, only that it would need to be considered per region, depending on local requirements. This allows countries/regions to opt-in to inheritance where needed, while keeping addresses simple in other areas where it would over-complicate things.

Until such a region specific proposal is made, mappers should continue adding alternate addresses as if they are completely separate addresses. This then allows contributors to later decide what tags should be inherited and what problems may arise based on real usage of alternate addresses in their country.

Numbered-suffix key

This proposal suggests that the first alternate address is tagged using addr:2:*, as the suffixless addr:* tags could be considered to be the "first" address, and this should be the least confusing option for most mappers.

• Usage of addr:0:* should be considered incorrect.
• Some mappers may want to use addr:1:* instead of addr:*. This is valid, but not recommended as this breaks addresses for software that does not support this proposal.
• addr:1:* should not be combined with addr:*.

More reasoning on this syntax

The pros/cons of this syntax is well-documented on Multiple values#Numbered suffix in key.

While pretty self-explanatory, I wanted to document existing usages of numbered-suffix keys as there is no consensus on where this syntax should start counting from. Additionally, due to the amount of addresses usually included in imports, an import that makes use of this proposal would likely have a long-term impact on this syntax.

Most usage of numbered-suffixes appears to begin at :1, and there doesn't seem to be a pattern on what the first number should be when paired with a suffixless tag:

• there are over 48k uses of source:1 in OpenHistoricalMap, 26.6k of those also have a regular source tag. [3] Of the 11.2k uses of source:2, 10.2k also have a source:1 tag, and 3.6k also have source. There is 1 use of source:0.
• there are over 35k uses of traffic_sign:2=*, which was deprecated in favour of semi-colon separated values. There are currently 11k uses of traffic_sign:3, and only 15 of traffic_sign:1.
• Key:panoramax#Multiple_images documents using numbered-suffixes to link multiple Panoramax images to an object, but the wiki page specifically states "there is no consensus on where to start counting". There are are 8k uses of :0, 3.5k of :1, and 1.1k of :2. Usage of :0 appears to be added automatically by certain editors (not chosen by a human). [4]
• seamarks lights have attributes tagged using seamark:light:<number?>:<attribute>, beginning from 1, such as seamark:light:1:colour=*. Seamark lights are only tagged with the numbered-suffix syntax if there is more than one light.
• website=* mentions website:1=* for tagging a second website. There are 8594 uses of website:1, and 561 uses of website:2.

Beginning with 2 is what the previous AddrN proposal used, with over 21k uses of addr2[5].

Tagging & Examples

Tagging follows the addr:*=* namespace, following local preferences.

Given most maps and other software will most likely only display one address, the primary address should always be whichever address is best to have displayed to users, or whichever address is most used by a feature. If an official address database suggests a primary address that does not match real-world usage, the real-world/on the ground address should always be tagged as the primary address.

Note: the way addresses are mapped can vary widely between regions! These examples may suggest tagging addresses on objects in a way that may be uncommon/discouraged in your country - different regions tag addresses directly on buildings, entrances, land plots, or even suggest keeping them as nodes separated from the main object. This proposal is only to support tagging multiple addresses on the same object, and otherwise shouldn't impact the way you map addresses in your country.

Image	Notes & Tagging
	House on the corner of two streets in Queensland, Australia. [6] Only the main address is used in practice, but valid addresses have been assigned to the land parcel regardless of whether there is an entrance for that street. Land parcels borders are displayed as white lines in this screenshot, but as they are rarely mapped it is common to tag addresses directly on buildings. Additionally, there is no entrance to tag 1 Cassowary Drive with. Main address: 193 Christine Avenue Alternate address: 1 Cassowary Drive addr:housenumber=193 addr:street=Christine Avenue addr:2:housenumber=1 addr:2:street=Cassowary Drive
	Another house in Queensland, Australia, this time bordering three streets. [7] Main address: 118 Sanctuary Parkway Alternate address: 25 Bellthorpe Crescent Alternate address: 15 Kondalilla Terrace addr:housenumber=118 addr:street=Sanctuary Parkway addr:2:housenumber=25 addr:2:street=Bellthorpe Crescent addr:3:housenumber=15 addr:3:street=Kondalilla Terrace

Impact on Data Consumers

By continuing to use the exact same addr:*=* namespace for primary addresses, data consumers can use and display the primary address of objects without any changes.

In areas where alternate addresses are not already included in the database, adding new addresses will have no impact on existing data, but will not be searchable until software adds support.

In areas that are already mapped with multiple addresses as separate nodes, mappers should avoid merging large amounts of data until popular software has support.

Features/Pages affected

• addr:*=*
• addr2:*=*

External discussions

• https://community.openstreetmap.org/t/rfc-feature-proposal-alternate-addresses/145406

Comments

Please comment on the discussion page.