Proposal:Turn lanes (relation)
 | An simpler alternative for the mapping of the indicated direction in which a way or a lane will lead is the turn(:lanes) tag. This tag has seen much more adoption and application support. In any case where this scheme is insufficient, Relation:connectivity can be used to clarify. As always in OSM you are however free to use this proposal. |
| Turn lanes | |
|---|---|
| Proposal status: | Obsoleted (inactive) |
| Proposed by: | benshu |
| Tagging: | type=turnlanes:turns |
| Applies to: |  relation
|
| Definition: | Relation for describing allowed turns from a given (turn) lane. |
| Statistics: |
|
| Rendered as: | Once renderers actually render lanes, arrows representing valid turns might be rendered as well. |
| Draft started: | 2011-03-14 |
| RFC start: | 2011-03-18 |
This proposal consists of lane directions and turn restrictions, but much finer in detail and emphasizes ease of use and practicality.
At some point lanes will (hopefully) be mapped as individual ways or areas as proposed elsewhere, giving maximum detail of their physical location and allowing for very detailed turn information. This proposal is an extension of the current model of putting lane count information in tags; this is practical now and enables easy-going editing of information.
There is a certain asymmetry to the proposed relation — they only describe length or count of the lanes leading up to a junction, not leading away from it. As long as there is at least one outgoing lane on a given road, one might be allowed to turn onto it. This asymmetry is in keeping with the spirit of this proposal, ease of use and practicality — at this point there is no rationale for considering outgoing lanes.
Rationale
While routers can use turn restrictions to figure out which turns are allowed and which aren't, they can just as well use the information provided by the proposed relation to help users find the right lane before junction.
The primary reason for designing the proposed relations is traffic simulation. Lane lengths and their allowed turns can have significant impact on the way traffic jams occur and develop and as such are required for detailed simulation. (Readers interested in traffic simulation can find more information at matsim.org.)
Plugin
A JOSM plugin called "turnlanes" is available which enables straight forward editing of turn lanes and allowed turns. In order to edit a junction make sure all ways are split at the junction node(s). Upon selecting the junction node(s) and via-way(s)-to-be the graphical editor should be initialized. Clicking the "+" signs will add turn lanes, selecting them will allow you to adjust their length. Turns are allowed by clicking on an "incoming" connector of one lane and dragging the mouse to the "outgoing" connector of another road.
Video demonstrations
The following two videos demonstrate how to tag junctions with the turnlanes plugin.
Hotkeys for editing
When the graphical editor has the focus, the following hotkeys are available.
| Hotkey | Effect |
|---|---|
| + | zoom in |
| - | zoom out |
| Spacebar | resets the view, centering on the junction |
| Ctrl+A | shows all turn connections; useful for getting an overview. |
| F5 | refreshes the model; useful after manual changes to the underlying relations |
| Ctrl+L | rotate left (counter-clockwise) |
| Ctrl+R | rotate right (clockwise) |
Turn lane lengths
This relation describes turn lanes for a given junction and road leading to it. While it is common for turn lanes on the right/left side of the road only to allow right and left turns respectively, this relation only concerns itself with the lanes and their length, not the allowed turns.
Given the example on the right we want to encode the information that there are two turn lanes on the left of the road with respective lengths of 37m and 32m as well as one on the right side of the road with a length of 20m. Also we need to model where their end which is node 1 and what path they take which is (starting at node 1) way 4 and then way 5.
The following relation is a simple translation of those requirements.
Tags
| Key | Value | Explanation |
|---|---|---|
| type | turnlanes:lengths | |
| lengths:left | turn lane lengths | the lengths of the turn lanes on the left side of the road, comma-separated, inside to outside |
| lengths:right | turn lane lengths | the lengths of the turn lanes on the right side of the road, comma-separated, inside to outside |
Members
| Way or node | Role | Recurrence | Discussion |
|---|---|---|---|
|
end | one | the junction node at which the turn lane(s) end |
|
ways | one or more | the path the turn lanes follow, in order, starting at the end node |
The argument has been made that geo information (here: lane lengths) should not be encoded in tags. To echo the introduction: This proposal tries to provide good detail while remaining practical and enabling straight-forward editing. The decision to encode lane lengths in tags directly rather than referring to a node on the road as its beginning was made to stay in keeping with those goals.
Example
This relation describes the turn lanes from the example above.
| Key or Role | Value |
|---|---|
| type | turnlanes:lengths |
| end | Node #1 |
| ways | Way #4 |
| ways | Way #5 |
| lengths:left | 37.0,32.0 |
| lengths:right | 20.0 |
Allowed turns
This relation describes the turns allowed from a given lane, very similar to the way in which the turn restrictions relation describes which turns are not allowed.
In order to model allowed turns from a given lane, it is necessary to somehow refer to that lane. To do this we partition the lanes into two subsets, regular lanes and extra lanes (extra lanes being lanes specified by the relation of the previous section) and address as follows:
| Lane Type | Addressing |
|---|---|
| regular | looking in the direction of the junction, from left to right, ascending and beginning at 1 |
| extra, right | looking in the direction of the junction, from left to right, ascending and beginning at 1 |
| extra, left | looking in the direction of the junction, from right to left, descending and beginning at -1 |
Given this schema describing allowed turns turns out to be rather trivial.
Tags
| Key | Value | Explanation |
|---|---|---|
| type | turnlanes:turns | |
| lanes | regular lane addresses, comma-separated | regular lanes from which one is allowed to turn |
| lanes:extra | extra lane addresses, comma-separated | extra lanes from which one is allowed to turn |
| access | see access | restricts access for the lane/turn; related tags are not listed, but may be specified also |
Members
| Way or Node | Role | Recurrence? | Discussion |
|---|---|---|---|
|
|
from | one | the way from which one is allowed to turn |
|
|
via | one (node) or one or more (ways) |
the junction at which one turns; see Dual Carriageways section for use cases involving one or more ways |
|
|
to | one | the way onto which one is allowed to turn |
Example
The following three relations describe the allowed turns as depicted on the right.
| Key or Role | left | straight | right |
|---|---|---|---|
| type | turnlanes:turns | turnlanes:turns | turnlanes:turns |
| from | Way #4 | Way #4 | Way #4 |
| via | Node #1 | Node #1 | Node #1 |
| to | Way #2 | Way #1 | Way #3 |
| lanes | 1 | 1,2 | <unset/empty> |
| lanes:extra | <unset/empty> | <unset/empty> | 1 |
Dual carriageways
Dual carriageways are roads where the two directions of traffic are divided. Such being the case, they are modeled as two seperate ways in OpenStreetMap. This poses the problem that the junctions where dual carriageways intersect with other roads consist of two or more nodes. This in turn means that a turn from or onto a dual carriageway may begin at one node and end at another. In order to model what happens inbetween the via-role of turn relations is allowed to be one or more ways.
Sometimes, for instance when two dual carriageways meet, there are two or more ways to model the via ways for the same turn. By convention and if possible the via ways should be chosen such that performing the turn does not involve driving against the direction of the way.
| Map | Notes |
|---|---|
|
Oftentimes there are two choices for via ways. Here a left turn coming from the north can be modeled by either using the yellow or green path in the via role. Conventionally the green path should be chosen, because the underlying ways' direction of traffic corresponds to that of the turn. |
|
Here a dual carriageway intersects with a one-way street. The only way to model the U-Turn coming from the south is by including the green path in the via role even though its direction of travel is opposite to that of the U-Turn. |
When editing dual carrigeways and complex crossings using the JOSM plugin, select all crossing nodes and ways which form the crossing to be able to edit relations with graphical interface.