Proposal:Boundary=address

From OpenStreetMap Wiki
Jump to navigation Jump to search
boundary=address
v · d
Proposal status: Canceled (inactive)
Proposed by: Miksuko
Tagging: boundary=address, addr:housenumber=*, addr:street=*
Applies to: area
Definition: An explicit, optional spatial container defining the verifiable area that is one specific address. Inner features inherit the address unless they carry a different tagged address.
Draft started: 2026-09-19
RFC start: 2026-09-19

Problem statement

There is no top-level feature for the extent of an address

The only near-universal property of addresses world-wide is that they refer to a location. They don't inherently define what the location is used for, nor do they inherently define who owns it. In many jurisdictions, an address is more than a point: it is a defined extent on the ground that covers curtilage, not just the buildings. Parking, playgrounds, driveways, yards, etc., are often all part of an address, even if it's not universal to tag them as such. An emergency services call from a courtyard 30 meters from any building is still in that address, yet without a encompassing address-tagged polygon reverse-geocoders fall back to nearest-neighbour guessing and might snap across back fences to the wrong street. What belongs to one address and what belongs to another is often identifiable on the ground, yet there is no consensus on how to map it, and OSM has no top-level tag that denotes only the extent of an address.

One might argue that landuse=* can be tagged with an address to define where an addressable area extends, but landuse=* inherently refers to the human use of an area of land. One address routinely spans many landuse types, for example landuse=industrial and landuse=landfill together, or landuse=commercial and landuse=industrial together (see #Examples). Hence a single landuse=* area can not always map the bounds of an address.

One might argue that place=plot already denotes the extent of an address, since plots are definite addressable areas. But place=plot inherently describes a land lot or cadastral parcel, asserting that the addressed area has a unique ownership. One address can span many parcels, such as with condos/strata, outparcels, and ground leases, and a single plot can likewise span multiple addresses. Hence place=plot can not always uniquely map the extent of an address even when the exact legal bounds are known.

Ambiguity of the meaning of addr:*=*

Since nothing else can hold the extent, addr:*=* on an area currently means two different things with no marker:

  1. Attribute: what address is this feature at? (e.g. address tags on a building=warehouse usually don't mean that the warehouse is the only thing at that address)
  2. Feature: where is this address on earth, and what are its bounds? (e.g. amenity=hospital features with address tags often cover the whole area that makes up the address)

Overcomplication and duplication of work

Without a container, the only way to describe that many things share one address is to copy the identical addr:=* block onto every building, yard, parking aisle, and POI inside it. A commercial or institutional site easily needs dozens of copies of the same housenumber + street + postcode. Every rename or correction must then be repeated N times. In practice, this leads to mappers adding address details to only an arbitrarily chosen subset of the features within the address.

This kind of duplication has already been eliminated elsewhere in OSM: is_in=* was deleted from millions of POIs (check out the drastic decrease on taginfo!) once boundary=administrative polygons + point-in-polygon made it inferable, and addr:country=* is now routinely omitted due to its obvious redundancy. A single boundary=address carrying the full addr:=* information lets every current and future feature inside inherit it spatially. Inner features need their own tags only when they are genuine exceptions with a different address.

But aren't address nodes already top-level features?

Nodes carrying only addr:*=* are already established top-level features in some places, especially in countries that import addresses from datasets, like the Netherlands and Denmark. Millions of them work fine today, and they are precedent that addr:*=* already functions as both attribute and feature. Nodes remain the correct mapping where the extent is unknown, unmappable, or point-sufficient (like in dense row housing).

For ways, however, the ambiguity described above applies. A polygon carrying landuse=industrial and addr:*=* could mean "this industrial area happens to sit at this address" (attribute) or "this polygon defines what is inside or outside the address" (feature). If ways with address tags were treated as address boundaries, we would have to pick one of two options:

  • treat every addressed landuse polygon as the definition of the boundary of its address, or
  • treat ways with only addr:*=* as boundaries, in which case adding landuse=industrial changes the way's meaning from "this is the extent of the address" to "this is just some of the extent of the address".

A point can't be mistaken for a landuse claim, so nodes don't have this problem. Ways do, so they need a way to mark the role explicitly.

Proposal

Introduce boundary=address as an optional top-level container for one civic address. boundary=address applies to closed ways and multipolygon relations.

No existing tags are deprecated or renamed. This does not replace address nodes, building addresses, or entrance nodes. It contains them. Mapping it is strictly optional, and doesn't apply to the many jurisdictions where addresses don't have defined boundaries.

Examples where existing tags aren't enough for the whole area

These are examples of areas that belong to a single address but where a single landuse=*, amenity=*, or place=plot polygon would not suffice to cover the extent of the entire address.

The address information on each feature in each of these examples could be inferred from a single boundary=address polygon that surrounded its corresponding area. Also, notice how much simpler it would be to be able to link the address boundary polygon itself in each of these, instead of having to reference specific buildings or landuse because they're the only features tagged with the address :^)

Rationale

A closed area for the address separates the address itself from the features inside it. We tag once, and let every shop, playground, and future building inside inherit address information via point-in-polygon, instead of duplicating identical addr:=* N times. This also matches how addresses actually work on the ground! In many jurisdictions, a feature has a specific address because it is within an address boundary. It only makes sense to map this single boundary if we know or can see where it goes.

Key:boundary was chosen because it is already the standard for intangible operational limits that are used as hierarchy containers, such as with two of its three most used values, boundary=administrative and boundary=postal_code. The tag is short and unambiguous when compared to place=plot (which maps ownership) and landuse=* (which maps function).

Verifiability and scope

The boundary is mapped only where a continuous observable perimeter exists, per Verifiability and On the Ground. If lawns are shared (e.g. duplex lawns), addresses are divided within an interior (e.g. stacked flats), or no perimeter is visible (e.g. informal settlements), no boundary is guessed. Addressed point-only objects (letterboxes, mileposts) stay as nodes. Cadastral or deed lines aren't traced, and no address ownership is asserted, unless that too is clear on the ground. A single home in a row of terraced houses should not get a duplicating boundary ring if the building=* polygon already clearly defines its individual address.

Significance and uses

  • Addresses should be independent of landuse and ownership. An address is not a landuse=* nor a land lot nor the shop currently renting the front unit. An area with housing + construction + woodland can share one address, and likewise one address can span three parcels with three owners. Tenants change every few years, but the address usually stays the same. A neutral container means mappers no longer have to split or merge landuse=* to fit addresses, claim single ownership with one big place=plot, or re-tag 30 shops when a typo is found.
  • A tag for verifiable perimeters and buildingless grounds. Fences, walls, and hedges often visibly delimit one addressed site, but the area they enclose currently has no established neutral tag. Mappers either overload landuse=* to mark it, or much more commonly, they leave it unmapped entirely. Address tags record the address fine, but nothing records how far that address extends.
  • Better geocoding. A search for "parking at 20 Street Road" today returns whatever parking happens to be nearby, including lots across the street that belong to someone else, unless the mapper has bothered to add an address to each feature. With an address boundary, any shop, locker, charger, playground, or parking aisle inside inherits the address spatially, so "features at this address" queries return confident and complete answers without a mapper having to duplicate addr:=* onto every object.
  • Better reverse-geocoding. Map apps already try to match arbitrarily dropped pins to addresses, but without a container they can only guess from what is nearby, sometimes snapping across a back fence to the wrong street. A coordinate inside a boundary=address is matched to that address unambiguously, whether the pin falls on a building or on open ground.
  • Better rendering. Renderers typically draw addr:housenumber=* and addr:unit=* on top of polygons that have these values set. If a dense cluster of buildings all share the same addr:housenumber=* and have different addr:unit=* values, the renderer often skips drawing the address label partially or entirely due to overlapping. A single address boundary polygon that covers the area could give the renderer an unambiguous label to render until the map's zoom level is close enough to discern individual buildings' address labels.
  • Better geofencing. An address only attached to a single building cannot geofence a 2-hectare logistics yard or apartment complex by itself. Delivery driver trackers and fleet management software need the full extent to distinguish being on site from being at the gate and from being at the door. The boundary answers confidently whether a position is inside the address, which a nearest-feature lookup cannot do.
  • Less cleanup and better QA. Tagging the address once means a change needs one edit instead of thirty. Once containers exist, validators can flag housenumbers far outside any plausible hull, mismatched street names, and unaddressed voids between same-address buildings.

Similar proposals

Proposal:Addr=main suggests a top-level tag to mark the primary routing location of an address (how to enter), whereas this proposal marks the extent of an address (what ground is this address).

Tagging

Tag Required? Meaning
boundary=address yes This polygon is the address extent (top-level feature).
addr:housenumber=* or addr:housename=* yes Primary identifier of the site.
addr:street=* if applicable Associated street.
addr:postcode=* recommended Postal code boundaries are mapped out in only a few countries, so the postcode can rarely be inferred from a containing polygon.
addr:city=* and addr:country=* no Rarely actually required, since geocoders already get the city and country from the surrounding administrative polygons. Nominatim works these out when it indexes the data and stores them in place_addressline. Komoot's Photon reads them back through its Nominatim importer and per-country address cache. Pelias does its own point-in-polygon lookup against Who's on First (wof-admin-lookup, OSM importer admin lookup).

Inner objects inherit the full addr:=* from the smallest containing boundary unless they carry a different tagged address.

Impact on data consumers

No existing tags are changed or deprecated. Polygons carrying only addr:=* are handled exactly as they are now, routing to buildings and entrances is untouched, and software that doesn't know about boundary=address will simply ignore it.

None of the benefits below exist yet, because each tool would first have to add support. osm2pgsql styles would need to keep the polygons, Nominatim would need to rank them and add them to place_addressline, and Photon and Pelias would need to import them.

  • Geocoders would check point-in-polygon containment first and fall back to proximity only outside any container. If address containers are nested, the smallest one has the highest priority. This removes cross-property mismatches in the areas where a boundary is mapped.
  • Routers and dispatch would keep routing to entrance and building points as today, and could additionally use the polygon to detect arrival on site. Some older stacks route to the centre of a polygon and snap to the nearest road, which can land on a rear alley instead of the front entrance. That is for those stacks to fix, for example by routing to mapped entrances or preferring roads whose name matches addr:street=*. It is not a reason to leave real extents out of the map.
  • Renderers currently draw address labels only on directly addressed features. If mappers stop tagging individual buildings inside a boundary, renderers would need to learn to take the label from the boundary instead. Hence it's not recommended to stop redundant address tagging until consumers catch up.

Features/Pages affected

  • Create Tag:boundary=address.
  • Update Key:boundary.
  • Update Key:addr and Addresses: make more explicit the inheritance rule, which is that inner objects inherit from smallest container unless they carry a different address.
  • Update Key:landuse: do not split/merge just to fit addresses.
  • Follow-ups: iD/JOSM presets, Nominatim/Photon/Pelias ingestion as container

External discussions

Comments

Please comment on the discussion page.

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal:Boundary%3Daddress&oldid=3081742"