Proposal:Traffic mirror relation using ways
| Traffic mirror relation using ways | |
|---|---|
| Proposal status: | Proposed (under way) |
| Proposed by: | Biff |
| Tagging: | type=traffic_mirror
|
| Applies to: | relation |
| Definition: | enhanced traffic mirror relation |
| Statistics: |
|
| Draft started: | 2025-03-04 |
| RFC start: | 2026-08-10 |
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.
Note: After several improvements to the proposal, its title no longer reflects the contents. The proposal will be renamed to "Proposal:Enhanced traffic mirror relation" after the RFC is completed and before voting starts.
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 useddirection=degreesto 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 traffic_mirror relation, see below. - Using a relation of
type=traffic_mirrorwith 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. 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 bydirection=degreesof the traffic mirror node.
Tagging
Tags
The relation is tagged as follows:
| Key | Value | Comment | Presence |
|---|---|---|---|
type |
traffic_mirror |
Defines this relation as a traffic mirror relation. | ! Required |
description |
text |
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 the "note" tag, if it might be helpful for other mappers.) |
? Optional/! Required |
note |
text |
Information for other mappers, e.g. specific information about what the relation represents, if this is not obvious. | ? Optional |
Members
| Role | Refers to | Comment | Presence |
|---|---|---|---|
|
 |
Node at the position of a mirror, typically tagged with highway=traffic_mirror. Typically, one traffic mirror relation can have only one "mirror" member. |
! Required |
|
|
The way or node from where the user (driver) drives 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 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.
A traffic mirror relation can have only one "from" member. 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. |
! Required |
|
|
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.
A traffic mirror relation can have only one "to" member. 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. |
! Required |
|
 |
The way (or node) that the user (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 his sitting position over the road and his 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, typically the "visible" way should continue beyond the "to" node. Also, it is not recommended to allow it to extend beyond the next intersection as the way is likely to be cut there in the future. The relation can have several "visible" members, if more than one way (or node) is visible from the from node through the mirror. If you can not tag the relevant "visible" members of the relation, you are required to use the "description" tag, see above. Note: For adding this member to a legacy traffic-mirror relation, see the "migration" section below. |
! Required/? Optional |
Migration from legacy relations
Legacy relations of type=traffic_mirror can be migrated to the new specification as follows:
- Check if the mirror node is properly tagged with
highway=traffic_mirrorand relevant attributes. Fix all mistakes. - Check if the existing relation indeed has three members that are nodes and with the roles
from - Identify the relevant way that is visible when looking into the mirror. Add it to the relation with the role
- In the case of a bidirectional mirror, make sure that it is a member of two valid relations - one for each viewing direction.
Examples
Simple example
This simple example shows the members of 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 traffic-mirror relation itself is tagged with type=traffic_mirror and the following members are added:
highway=traffic_mirror
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 traffic-mirror relation itself is tagged with type=traffic_mirror and the following members are added:
highway=traffic_mirrorhighway=stop,direction=forward(ordirection=backward, as applicable)
- Relation #2
The traffic-mirror relation itself is tagged with type=traffic_mirror and the following members are added:
Two mirrors in different places
This advanced example is based on the relations https://www.openstreetmap.org/relation/19313347 and https://www.openstreetmap.org/relation/19313348 but has been slightly modified to always show the car driving from left to right (west to east).
One side street is crossing a priority street. Two separate mirrors exist to see both directions of the priority street.
N
|
^
^ #1
W----------*---o-----------------E
v #2
v
|
S
- Relation #1
The traffic-mirror relation itself is tagged with type=traffic_mirror and the following members are added:
#1Node:highway=traffic_mirror*Node:highway=stop,direction=forward(ordirection=backward, as applicable)oNode: tovWay: visible
- Relation #2
The traffic-mirror relation itself is tagged with type=traffic_mirror and the following members are added:
#2Node:highway=traffic_mirror*Node:highway=stop,direction=forward(ordirection=backward, as applicable)oNode: to^Way: visible
Mirror in curve
Example of a bi-directional mirror located in a curve and how it is tagged using two relations.
N
#
W------<<<<*1<<o E
v
*2
v
|
S
This example is based on the relations https://www.openstreetmap.org/relation/21219527 and https://www.openstreetmap.org/relation/21219528 but has been slightly modified to either show the car driving from left to right (west to east) to turn right or driving from bottom to top (south to north) to turn left.
- Relation #1
The traffic-mirror relation itself is tagged with type=traffic_mirror and the following members are added:
#Node:highway=traffic_mirror*1Node: fromoNode: tovWay: visible
- Relation #2
The traffic-mirror relation itself is tagged with type=traffic_mirror and the following members are added:
#Node:highway=traffic_mirror*2Node: fromoNode: to<Way: visible
Simple dead-angle mirror
This example is based on the relation https://www.openstreetmap.org/relation/21279680 but has been slightly modified to either show the car driving from left to right (west to east).
N
|
|
|
W------<<<<*<o-+-----------------E
# |
|
|
S
The traffic-mirror relation itself is tagged with type=traffic_mirror and the following members are added:
#Node:highway=traffic_mirrorat the actual position of the mirror*Node:highway=traffic_signalsandtraffic_signals:direction=forward(ortraffic_signals:direction=forward, as applicable).oNode:<Way:
Dead-angle mirror at advanced stop line
Example of dead-angle mirror at a junction with an advanced stop line and with traffic signals tagged at the stop line.
N
|
|
|
W------<<<<*<o-+-----------------E
# |
|
|
S
The traffic-mirror relation itself is tagged with type=traffic_mirror and the following members are added:
#Node:highway=traffic_mirror*Node:highway=traffic_signals,direction=forward(ordirection=backward, as applicable)oNode:cycleway=asl,direction=forward(ordirection=backward, as applicable)<Way:
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 better see into the direction given by traffic_mirror=*.
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_mirrorshould 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_mirrorshould 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 has been posted to https://community.openstreetmap.org/t/title-rfc-feature-proposal-traffic-mirror-relation-using-ways/146318 .
Comments
Please comment until 12 September 2026 on the discussion page or https://community.openstreetmap.org/t/title-rfc-feature-proposal-traffic-mirror-relation-using-ways/146318 .