Proposal:Gantry Expansion

Gantry Expansion
Proposal status:	Proposed (under way)
Proposed by:	SherbetS
Tagging:	Data item
Statistics:
Draft started:	2026-09-04
RFC start:	2026-09-20

Problem Statement

The man_made=gantry tag documentation page sprung up to document the widespread use of the tag to describe highway and occasionally railway gantries.

The page mentions in passing some undocumented keys that are being used to describe some functions and constructions on some gantry, but there is zero guidance on any recommended tagging scheme for the use and structure of a gantry.

An example is gantry:type=*, which is mentioned on the gantry page but there is no documentation. It has over 2,000 uses so there is definitely a demand for a tagging scheme to represent other gantry attributes.

gantry:type=*

More details at taginfo

More details at taginfo

This proposal aims to establish a sensible and extensible tagging scheme that can be used to describe the great diversity of gantries present in the real world.

Additionally, the archived proposal for man_made=gantry suggests that each node on the gantry represents a support, but this makes no sense in the case of a cantilever gantry, or one where nodes are being used to represent some object mounted to the gantry, such as a variable message sign or camera.

Presently, the proposal does not aim to change the tagging for highway=toll_gantry, since it is represented by a node along a road to be used as a routing feature. The physical gantry bearing the toll cameras can be represented using a way and man_made=gantry, but the node scheme can be preserved for the sake of routing.

Proposal

I propose:

1. Establish a new namespace, gantry:*=* to be used in combination with man_made=gantry
2. Expand the definition of structure=* to describe the structure of gantries.
3. Under the new namespace, add the key gantry:type=* to describe the supporting design of the gantry.
4. Under the new namespace, establish a new namespace, gantry:use:*=*. This can be used to describe all the uses of the gantry and can be used to describe gantries that fit into more than one use category (ex: a gantry with a variable message sign and toll cameras). This mirrors how service:vehicle:*=* is used to describe the different services that a shop=car_repair provides.
5. Establish that each node in a way representing a gantry does NOT represent a support, unless it is explicitly tagged with a support=* value.
6. Establish the default value layer=1 for all gantries, and document that layer should be one greater than the road the gantry overhangs.

Rationale

Rationale

• The new scheme will provide a documented way to tag the construction and use of the gantry in a way that is easy to query, without using semicolons.
• The new scheme will provide a way to represent the supports of the gantry, while also allowing other features to be conceptually attached to the gantry, as well as leaving room to tag gantries that are only supported on one side.
• The new scheme will be flexible to how much detail the mapper chooses to add, just specify that a gantry exists, optionally specifying supports, structure, construction, and what the gantry is used for.

Tagging

structure=*

Value	Description	Image
lattice	The gantry structure is a (generally metal) lattice
tube	The gantry structure is a metal tube
beam	The gantry structure is a beam
solid	The gantry is a solid structure

gantry:type=*

Value	Description	Image
portal	The gantry structure spans across at least 2 supports with the road or rail passing beneath
cantilever	The gantry structure is supported by a single support structure on one side also known as a half gantry or butterfly gantry.

gantry:use:*=*

Firstly, the type of gantry use is defined.

tag	description
gantry:use=highway	The gantry serves a highway feature
gantry:use=railway	The gantry serves a railway feature

Then,

key	description	example
gantry:use:destination_sign=yes	the gantry features a destination sign, often signalling an exit on a limited access road
gantry:use:variable_message=yes	the gantry features a variable message sign, often for traffic information or emergencies
gantry:use:toll=yes	The gantry features cameras and/or sensors for toll enforcement
gantry:use:speed_camera=yes	The gantry features cameras and/or sensors for speed enforcement
gantry:use:camera=yes	The gantry features surveillance cameras for traffic monitoring
gantry:use:signals=yes	The gantry features signals that can be activated in the event of emergency or other circumstances
gantry:use:railroad_signals=yes	The gantry features signals used on a railroad
gantry:use:railroad_crossing=yes	The gantry is part of a railway=level_crossing bearing signals or other relevant equipment
gantry:use:*=yes	freeform values can be used to describe edge cases that aren't documented

support=*

The support key can be used to describe the gantry supports

tag	description	example
support=lattice	The gantry is supported by a latticed structure support
support=pole	The gantry is supported by a pole
support=beam	The gantry is supported by a beam

Examples

Tagging a gantry with multiple purposes

Impact on Data Consumers

The goal of this proposal is to give a rich and specific tagging scheme for gantries that supports a variety of different use cases, especially cases where a gantry features more than one use, which (in my opinion) is better supported using prefixed keys than semicolons.

The current tagging of man_made=gantry will be preserved, and the additional keys will remain optional, therefore a mapper can choose how much detail to specify at a given gantry without being obligated to tag exhaustively.

Features/Pages affected

man_made=gantry

External discussions

https://community.openstreetmap.org/t/rfc-feature-proposal-gantry-expansion/147943

Comments

Please comment on the discussion page.