Proposal:Enhanced traffic mirror relation

Enhanced traffic mirror relation v · d
Proposal status:	Voting (under way)
Proposed by:	Biff
Tagging:	`type=traffic_mirror` Data item
Applies to:	relation
Definition:	enhanced traffic mirror relation
Statistics:
Draft started:	2025-03-04
RFC start:	2026-08-10
Vote start:	2026-09-17 00:00:00 (UTC)
Vote end:	2026-09-30 23:59:59 (UTC)

Proposal

This proposal suggests to replace the loose "in use" specification of the relation given in in highway=traffic_mirror with a well-defined "approved" specification. For the already defined "from" and "to" members of the relation, it provides better guidance for their meaning and the selection of their location, also covering additional situations like bidirectional mirrors in curves and dead-angle mirrors. Additionally, the proposal defines a new and recommended "visible" member to indicate relevant ways (or nodes) that can be seen through the traffic mirror.

This proposal does not cover additional attributes for a node tagged with highway=traffic_mirror. Several improvements have been discussed, but they will be the subject of a separate proposal at a later point in time.

Rationale

Currently, highway=traffic_mirror specifies two options for tagging of traffic mirrors:

Simply tagging the node where the mirror is located with highway=traffic_mirror:
This provides no info about how the mirror is intended to be used. Sometimes, taggers have used direction=degrees to provide information about the direction in which the mirror is facing. However, a navigation system would have to do rather complex calculations to find out if the mirror is relevant for a driver. This situation can be improved by using a relation, see below.
Using a relation of type=traffic_mirror with three nodes of the types "from", "to" and "mirror".
The currently existing guidance for selection of the "from" and "to" members is considered incomplete and easy to misunderstand. Several readers thought that these roles are intended to be similar to those of a turn-restriction relation. However, this is not the case, because does not matter in which direction the driver turns after crossing the junction. Instead, the "from" and "to" roles are similar to those of an enforcement relation. This proposal tries to provide a clear specification of the relation.

Additionally, this proposal improves the specification of "from" and "to" members to cover more situations, such as bi-directional mirrors placed in curves and dead-angle mirrors, and more clearly says which nodes should be used. The new and recommended "visible" member indicates relevant ways (or nodes) that can be seen through the traffic mirror, which is easier to use than the information provided by direction=degrees of the stand-alone traffic mirror node.

Tagging

Members

Role	Recurrence	Comment
`mirror`	! 1	Node at the position of a mirror, typically tagged with `highway=traffic_mirror`.
`from`	! 1	Node from where a driver can typically start using the mirror. If the mirror is used to allow view from a street into a priority street, this is the node tagged with `highway=stop`, `highway=give_way` or simply where the vehicle typically stops and the driver starts using the mirror. In the case of a dead-angle mirror, this is the node used for tagging the stop line, which is typically a node already tagged with `highway=traffic_signals`. Note: The usage of "from" and "to" nodes is similar to those in a enforcement relation and different from the "from" and "to" ways in a turn restriction relation.
`to`	! 1	Node where it stops making sense to look at the mirror. In the case of a mirror that provides view of a priority street, this is typically the node that connects the way with the "from" node and the way of priority street. In the case of a mirror in a curve or a dead-angle mirror, this is a node on the road next to the mirror. Note: Unlike a enforcement relation, where the "to" member is only needed if an enforcement device is placed in a way such that it differently affects vehicles going to different directions, the relevance of a mirror typically does not depend on the direction where the vehicle goes after passing the junction or curve. In the traffic mirror relation, the "to" node is mandatory because no "device" node exists that could be used to identify relevant vehicles based on their travel direction.
`visible`	! 1+	All ways (or nodes) that a driver sees when using the mirror. An exact limit for the visible section of a street is difficult to define as it depends on the height of the driver, the height of their sitting position over the road and their capability of seeing small objects in the mirror. Therefore it typically does not make sense to try to be precise and cut down an existing way. However, future splits of a long way by other people could leave it ambiguous whether a member is actually visible or not. The usefulness of the mirror also rarely extends beyond the next intersection even if the way is visible. Sometimes, especially if the visible street has been cut up into very short ways close to the mirror, there can be more than one `visible` member. In specific situations, nodes might also be "visible" and can be added as `visible` members; but nodes that are part of a way that is a `visible` member shall not be added as individual members. If the "visible" members of the relation aren't sufficient to describe what can be seen in the mirror, use `description=*` to add that detail.

Confidence check for tagging

The relation is tagged with type=traffic_mirror.
The relation has the following members:
1. At least four members: One each of from, to, and mirror, one or more of visible.
2. At least three members: One each of from, to, and mirror. This is only allowed if the description=* tag of the relation describes the situation.
The mirror member is tagged with highway=traffic_mirror and relevant attributes.
Bidirectional mirrors are part of two relations - one for each viewing direction.

Migration from legacy tagging

The mirror node is tagged with highway=traffic_mirror. If it isn't part of a traffic mirror relation yet, add it as a mirror member.

Legacy relations of type=traffic_mirror can be migrated to the new specification as follows:

The from member might be missing. In that case, it has to be added by looking for an appropriate node.
The to and mirror members from the legacy relations are used in the same way as specified here.
Legacy relations don't have visible members. They have to be added like they would be for a new relation.
If only a single legacy relation exists for multiple mirrors on the same pole or a bidirectional mirror, then one or more additional relations have to be added. Each mirror needs its own relation. A bidirectional mirror needs two relations, one relation for each viewing direction.

While you are at it, it is recommended to also check that the attributes of the traffic mirror are correct and up-to-date, and the from and to members are in the correct place.

Examples

Simple example

This simple example is based on the relation https://www.openstreetmap.org/relation/18783095.

A traffic mirror is placed at a junction to allow the driver of a vehicle to see other vehicles that have priority (coming from the right in a country where vehicles drive on the right side of the road).

The relation itself is tagged with type=traffic_mirror and the following members are added:

mirror: Node tagged with highway=traffic_mirror
from: Node at the approximate position on the street from where the mirror typically starts to be useful. (In this example, no stop or give-way node exists that could be used as a "from" member.)
to: Junction node
visible: Visible way to the right of the junction (from the perspective of the driver)

Two mirrors in same place

This advanced example is based on the relations https://www.openstreetmap.org/relation/18617969 and https://www.openstreetmap.org/relation/21279627 .

In this example, two mirrors (for looking left and right) are mounted to a single pole located opposite the exit of a supermarket's parking lot. Additionally, a stop sign exists at the exit.

Relation #1

The relation itself is tagged with type=traffic_mirror and the following members are added:

mirror: Node tagged with highway=traffic_mirror
from: Node tagged with highway=stop, direction=forward (or direction=backward, as applicable)
to: Junction node
visible: Visible way to the right of the junction

Relation #2

The relation itself is tagged with type=traffic_mirror and the following members are added:

mirror: Same highway=traffic_mirror node as in relation #1, multiple traffic mirrors on the same pole are tagged with a single node.
from: Same highway=stop node as in relation #1
to: Same junction node as in relation #1
visible: Visible way to the left of the junction

Two mirrors in different places

This advanced example of two traffic mirrors in different places of one junction is based on the relations https://www.openstreetmap.org/relation/19313347 and https://www.openstreetmap.org/relation/19313348 .

A side street is crossing a priority street. Two separate mirrors exist to see both directions of the priority street.

Relation #1

The relation itself is tagged with type=traffic_mirror and the following members are added:

mirror: First node tagged with highway=traffic_mirror, to the left of the junction
from: Node tagged with highway=stop, direction=forward (or direction=backward, as applicable)
to: Junction node
visible: First visible way, to the right of the junction. (Street section between junction and traffic island.)
visible: Second visible way, to the right of the junction. (Street section beside island.)

Relation #2

The relation itself is tagged with type=traffic_mirror and the following members are added:

mirror: Second node tagged with highway=traffic_mirror, to the right of the junction. This is not the same highway=traffic_mirror node as in relation #1
from: Same highway=stop node as in relation #1
to: Same junction node as in relation #1
visible: Visible way, to the left of the junction

Mirror in curve

This advanced example of a bi-directional mirror located in a curve and how it is tagged using two relations is based on the relations https://www.openstreetmap.org/relation/21407466 and https://www.openstreetmap.org/relation/21407467 .

Relation #1

The relation itself is tagged with type=traffic_mirror and the following members are added:

mirror: Node tagged with highway=traffic_mirror.
from: Node on the street, approximately where one viewing direction through mirror starts to become useful.
to: Node on the street, in the curve, close to the mirror.
visible: Visible way on other side of the curve, in this viewing direction.

Relation #2

The relation itself is tagged with type=traffic_mirror and the following members are added:

mirror: Same highway=traffic_mirror node as in relation #1.
from: Node on the street, approximately where this other viewing direction through the mirror starts to become useful. This is not the same node as in relation #1.
to: Node on the street, in the curve, close to the mirror. In this example, this is the same node as in relation #1.
visible: Visible way on other side of the curve, in this viewing direction. This is not the same way as in relation #1.

Simple dead-angle mirror

This example of a simple dead-angle mirror is based on the relation https://www.openstreetmap.org/relation/21279680 .

A dead-angle mirror is placed at a junction to allow the driver of a truck or bus to see bicycles and pedestrians that are located in front of or at the side of the vehicle.

The relation itself is tagged with type=traffic_mirror and the following members are added:

mirror: Node tagged with highway=traffic_mirror at the actual position of the mirror
from: Node at the stop line tagged with highway=traffic_signals, direction=forward (or direction=backward, as applicable)
to: Node on the road at the lateral projection of the actual position of the mirror (which is typically mounted to the same pole that also supports the traffic light at its actual position).
visible: Visible way from the "to" node back to approximately one bus length or truck length behind the "from" node

Dead-angle mirror at junction with advanced stop line

This example of a dead-angle mirror at a junction with an advanced stop line is based on the relation https://www.openstreetmap.org/relation/21402812.

A dead-angle mirror is placed at a junction to allow the driver of the truck or bus to view bicycles between the advanced stop line (where bicycles stop) and the normal stop line (where the truck or bus stops) and also bicycles at the side of the vehicle.

Example of dead-angle mirror at a junction with advanced stop line

The relation itself is tagged with type=traffic_mirror and the following members are added:

mirror: Node tagged with highway=traffic_mirror at the actual position of the mirror.
from: Node at the stop line tagged with highway=traffic_signals, direction=forward (or direction=backward, as applicable).
to: Node at the advanced stop line for bicycles tagged with cycleway=asl, direction=forward (or direction=backward, as applicable).
visible: Visible way from the "to" node back to approximately one bus length or truck length behind the "from" node.

Rendering

The rendering of the mirror node is specified in highway=traffic_mirror.

The relation as such is not rendered, but it can be used by a navigation system. The navigation detects that a driver is about to drive through the "from" node followed by the "to" node. Before reaching the "from" node, the navigation system should make the driver aware that a traffic mirror is available to see the "visible" member(s).

Features/Pages affected

If the proposal is approved:

Relation:traffic_mirror should be created and all information about the relation should be available on that page. (Similar pages exist for other relations, e.g. Relation:site.)
type=traffic_mirror should be created as a redirection to Relation:traffic_mirror. (Similar redirections exist for other relations, e.g. type=site.)
The overview of established relations on type=* should be amended.
highway=traffic_mirror should to be edited to replace the outdated info about the relation with a link to Relation:traffic_mirror.
The role pages Role:mirror, Role:from, Role:to and Role:visible should be updated or created.

External discussions

The idea for this proposal started on Talk:Tag:highway=traffic mirror.

The RFC was posted to https://community.openstreetmap.org/t/title-rfc-feature-proposal-traffic-mirror-relation-using-ways/146318 .

Comments

Comments were collected on the discussion page and https://community.openstreetmap.org/t/title-rfc-feature-proposal-traffic-mirror-relation-using-ways/146318 .

Voting

Instructions for voting

Log in to the wiki if you are not already logged in.
Scroll back down and click "Edit source" next to the title "Voting". Copy and paste the appropriate code from this table on its own line at the bottom of the text area:

To get this output	you type	Description
I approve this proposal.	`{{vote\|yes}} --~~~~`	Feel free to also explain why you support the proposal!
I oppose this proposal. reason	`{{vote\|no}} reason --~~~~`	Replace reason with your reason(s) for voting no.
I have comments but abstain from voting on this proposal. comments	`{{vote\|abstain}} comments --~~~~`	If you don't want to vote yes or no but do have something to say. Replace comments with your comments.

Note: The ~~~~ automatically inserts your name and the current date.
For more types of votes you can cast, see Template:Vote. See also how vote outcome is processed.

I approve this proposal. The proposal includes all comments that were collected during the RFC discussion. I'm not aware of any gaps and think that it's now ready for approval. --Biff (talk) 20:34, 17 September 2026 (UTC)[reply]

I approve this proposal. --Jofban (talk) 21:28, 17 September 2026 (UTC)[reply]

I approve this proposal. --Nielkrokodil (talk) 21:51, 17 September 2026 (UTC)[reply]

I approve this proposal. I like that it's simple and can seemingly describe most situations. --Martinligabue (talk) 11:28, 18 September 2026 (UTC)[reply]

I approve this proposal. --pkoby (talk) 18:18, 18 September 2026 (UTC)[reply]

I approve this proposal. Glad to see the migration guidance and the required "visible" role both made it in from the RFC discussion; that addresses the points I raised there. --Chris debian (talk) 10:25, 20 September 2026 (UTC)[reply]

I approve this proposal. not sure why the voting section was not visible, had to edit the whole page instead the section, trimming spaces around Voting --Nospam2005 (talk) 14:59, 20 September 2026 (UTC)[reply]

I can't reproduce an issue with the Voting section not being visible or the link from the TOC to the Voting section not working. If any other voter experiences a similar problem: please raise your hand. --Biff (talk) 08:12, 21 September 2026 (UTC)[reply]

I approve this proposal. Seems to be sufficiently though through and I'm not aware of anything that would make me object to it. --comfyquiettree (talk) 13:02, 21 September 2026 (UTC)[reply]

I approve this proposal. I'm not sure that the to has to be mandatory, but I don't think it's a make-or-break issue. Besides, I didn't state that as a comment before. Duja (talk) 18:17, 21 September 2026 (UTC)[reply]

Key	Value	Presence	Comment
`type`	`traffic_mirror`	! Required	Defines this relation as a traffic mirror relation.
`description`	`text`	‽ Important	Human-readable text that can be shown to users. The text should contain information about the mirror that is not given by relation members or by attributes of the mirror. This tag is required, if for any reason the relation does not contain all relevant "visible" members. In this case, the description shall describe what can be seen through the mirror. If all relevant "visible" members are later added to the relation, redundant information shall be deleted from the "description" tag. (In this case, the information can be moved to a "note" tag, if it might be helpful for other mappers.)

Proposal:Enhanced traffic mirror relation

Contents

Proposal

Rationale

Tagging