Proposal:Turn lanes (way)

Turn Lanes
Proposal status:	Rejected (inactive)
Proposed by:	Zverik
Tagging:	lanes:*=*
Applies to:
Definition:	Marking turn lanes in a highway
Statistics:
Rendered as:	Road signs or markings
Draft started:	2011-09-29
RFC start:	2011-10-06
Vote start:	2012-01-09
Vote end:	2012-01-31

Summary

There is no single approved standard in OSM to mark turn lanes of roads. But navigation software these days have means to display and route lane-wise. So, it is time to establish a tagging scheme.

The proposal consists of the following parts:

1. number of turn lanes, lanes for PSV and for going straight (e.g., lanes:turnright:forward=1);
2. description of non-standard lane arrangements (e.g., lanes:psv:location=left);
3. connection between a lane and ways a driver must go if he won't change lanes (relation type=lane_restriction).

All three constitute a complete tagging system.

Do not be frightened by the size of this proposal page: most of it are examples, and all descriptions of proposed features fit in one screen. Check frequently asked questions to better understand some points.

Number of lanes

Tagging as defined in this section is mandatory. Two other tagging schemes are used to aid processing software and human readers in complex cases.

Total number and directions

This is already being used (except lanes:reversible), just to state it here for completeness.

1. "Lane" means any one of the longitudinal strips into which the carriageway is divisible, whether or not defined by longitudinal road markings, which is wide enough for one moving line of motor vehicles other than motor cycles (from Vienna Convention on road signs and signals).
2. Total physical number of lanes on the road is tagged with lanes=*.
3. Number of physical lanes in one direction is tagged with lanes:forward=* and lanes:backward=* with regard to the direction of the way.
4. If there are reversible lanes, their number is stated in lanes:reversible=*. Those lanes are added to either lanes:forward or lanes:backward depending on road signs or signals, but may be omitted from calculations for simplicity.

It is not necessary to state both lanes:forward and lanes:backward: one can be determined from the other and lanes, for example:

lanes:forward = lanes - lanes:backward - lanes:reversible

Lanes number for directions may be omitted completely in following cases:

• Oneway road (oneway=yes) with no reversible or PSV lanes that make this road two-way;
• Each direction of a road is mapped as a separate way (the same as the first case);
• The road has two regular lanes, one lane in each direction.

If a two-way road has more than two lanes, regardless of evenness of number, lanes number for directions is ambiguous and should be stated in lanes:*.

Number of different lane types

Each lane on the road leads to another way after a crossing. On a crossing ways are divided into groups: straight, left and right (and, sometimes, back). This is drawn in reality with road signs and road markings. Lanes are divided into groups: those from which you can drive through, or from which must turn. Turn lanes for left turn are always located on the left side of a road, and right turn is possible only from the rightmost lanes. Is is not so clear for U-turn lanes: in most countries they are at the left, but in UK — at the right side of a road.

Anyway, the task is to determine the number of lanes for each direction, including 'through'. The tags are, therefore, obvious:

1. There is a fixed number of possible lane types:
   • through
   • turnleft
   • turnright
   • turnback
   • merge
   • bus
   • psv (buses + other, like taxis or trolleybuses)
2. The number of lanes of a specific type is tagged with lanes:<lane type>=*.
3. In case there are two directions on a highway, the tag is lanes:<lane type>:<direction>=*. The direction (forward/backward) is a suffix, just like with lanes and already used lanes:psv=*.
4. If a number of lanes:through is not set, it is calculated from other tags:

lanes:through = lanes - Ʃ(lanes:*)

The explicit value of lanes:through must be stated when there are more then two types of turn lanes, or some turn lanes allow going straight.

Numbering lanes

This is not relevant to the above mentioned tags, but lanes are numbered from outside to inside. That is, the first lane is the rightmost one for right-hand traffic and leftmost one otherwise.

Every lane type has default position:

• turnback — on the inner side (starting from lanes);
• turnleft — leftmost lanes;
• turnright — rightmost lanes;
• merge / psv / bus — on the outer side (starting from 1), along with turning lanes;
• tram lanes (if they are somehow marked) — on the inner side, along with turning lanes.
• through — in all lanes without lanes of other types, and also, if lanes:through is greater that the number of unfilled spaces, turn lanes first between group of through lanes, then at sides of the group: first outside, then inside.

If a group of lanes is not in default position, see #Lane Positions.

Examples

First of all, the answer to the question «How do I map lanes where rightmost lane is for both going through and turning right?» is, you don't.

By default, lanes that are closest to sides of the road (one lane each) can be used both for going through and turning — if there is a turn. If lanes:turn* is specified, then the lanes mentioned can be used only for turning.

What if you cannot turn left or right at the next intersection? Use turn restrictions then.

Simple

(Assuming a way is drawn from left to right)

lanes=6
lanes:forward=3
lanes:turnleft:forward=1
lanes:turnleft:backward=3

turnleft:backward is actually not needed, since there must be a turn restriction restricting drivers from going right or forward.

lanes=3
lanes:turnleft=1
lanes:through=3

Again, lanes=3 should be enough: this distribution of lanes can be considered default. There must be a turn restriction forbidding right turn and making the rightmost lane a through one. So, in most cases a turn restriction defines a set of lanes for a part of the road that does not need additional tagging (see below for directions building algorithm).

Five parts:

lanes=3

lanes=3

lanes=4
lanes:turnleft=1
lanes:merge=1

lanes=3
lanes:merge=1

lanes=2

S Orange Ave, Orlando, FL

NE2 made a pretty picture of a road with a lot of turn lanes. Let's try to apply this tagging scheme, considering that the road is drawn with a single way broken at red lines, direction of each segment is from top to bottom:

lanes=5
lanes:forward=2
lanes:turnleft:backward=1

lanes=4
lanes:forward=2

lanes=5
lanes:forward=3
lanes:turnleft:forward=1

lanes=6
lanes:forward=4
lanes:turnleft:forward=2

lanes=7
lanes:forward=2
lanes:turnleft:backward=2
lanes:turnright:backward=1

lanes=6
lanes:forward=2
lanes:turnleft:backward=1
lanes:turnright:backward=1

lanes=4
lanes:forward=2

lanes=5
lanes:forward=3
lanes:turnleft:forward=1

Not so hard, actually. The defaults that were in use in this example:

• lanes:backward = lanes - lanes:forward
• lanes:through = lanes - lanes:turnleft - lanes:turnright

If there were a lane that's both turnleft and straight, we'd have to specify lanes:through.

Ambiguity

• lanes=3
• lanes:turnleft=1
• lanes:through=2
• lanes:turnright=1

As one can see, the exact distribution of lanes cannot be constructed from just those tags (in this case, though, it can -- if :though and :turnright are omitted). That's why the next section is introduced.

Lane positions

In non-standard lane arrangements, for example, when bus lane is the leftmost one, lanes:bus is not enough, because by default bus lanes are on the right (for right-hand traffic). Also, if some lanes allow both turning and going straight (and through lanes are not arranged evenly), lane arrangement is ambiguous. For those cases, locations of some lanes should be stated.

lanes:X:location=* is the number of the first lane in lane group X, or a special keyword for denoting where the lane is: left, right or sides (two equal groups both on inside and outside of a road). For the example above, the additional tag will be lanes:through:location=right (or 1 for right-hand traffic, or 2 for left-hand traffic).

Considering this notation, the default values for special and turn lanes are as follows:

• lanes:turnleft:location=left
• lanes:turnright:location=right
• lanes:turnback:location=<lanes - lanes:turnback + 1> (moving turnlanes from the edge)
• lanes:merge/psv:location=1 (along with turn lanes)

As with other lane tags, if there are two directions for one way, lanes:X:location:forward/backward=* may be used — but it is strongly recommended to divide such ways in two directions to simplify tagging.

Examples

This is a British road, left-hand traffic. Assuming ways are directed from bottom to top.

Top:
 lanes=7
 lanes:forward=4
 lanes:turnleft:forward=1
 lanes:turnright:forward=2
 lanes:through:forward=3
 lanes:through:location:forward=left (not required, actually)

Bottom:
 lanes=6
 lanes:forward=3
 lanes:psv:forward=1
 lanes:psv:backward=1
 lanes:psv:location:backward=right

The rightmost lane is used for turning right, but it is also a bus lane (where PSVs can go straight).

lanes=4
lanes:psv=1
lanes:turnright=1
lanes:turnright:location=1

Actually, this one is unambiguous without :location, but is a nice example of tagging by the photo.

Building lane directions

For a convenient presentation, lanes:* tags should be converted into a number of directions for each lane, like on road signs:

For simplicity, we will use the following characters separated by commas, from left to right:

• s — through lane;
• l — left;
• r — right;
• u — u-turn;
• m — merge;
• p — psv/bus.

For example, the sign above can be written as l,l,sl. Note that lane numbers start from left for a left-hand traffic and from right for a right-hand traffic. Outer side is lanes 1,2,etc; inner side is N,N-1,etc (where N is a value of lanes tag). If *:location=L, the group of lanes fills lanes L,L+1,etc.

1. Prepare an array of empty lane directions for the number of lanes on the required road direction.
2. For each lanes:X:location except lanes:through:location put the corresponding lane group into specified position and skip the step for placing them.
3. For each lanes:turnback, lanes:turnleft and lanes:turnright add the required number of lanes in empty places of the array: 'u', 'l' and 'r'.
4. For each lanes:psv and lanes:merge append 'p/m' (depending on the remaining number of each lane type) to the lanes starting from the outer one.
5. If there is a highway ahead (forward direction), fill the rest of empty lanes with 's'.
6. If there is a lanes:through tag and its value is greater that the number of 's' in the array:
   1. if a lanes:through:location is present, fill the array with 's' from that lane up;
   2. otherwise, append those letters one by one to the neighbouring lanes of already marked as 'through': first outside, then inside. Do not touch lanes that are marked with 'm' or 'p'.
7. If there were no turnleft tags and there is an allowed left turn ahead, add an 'l' to the left edge, one or more, for each special lane. The same for turnright tags.

Visual description

The description is for a right-hand traffic:

1. Empty array: ,,,,,,,,,,,,,,
2. Placing explicitly located turn/special lanes: pl,l,,,,,r,r,pm
3. Turn lanes: u,l,l,l,,,,,,,r,r,r
4. PSV and merge lanes: u,l,l,l,,,,,,,r,rp,rpm
5. Through lanes: u,l,l,l,s,s,s,s,r,rp,rpm
6. The rest of through lanes:
   1. if there is an explicit location: u,l,ls,ls,s,s,r,rp,rpm
   2. otherwise: u,l,l,ls,s,s,rs,rs,rp,rpm
7. Turn lanes if there were none: sl,s,s,s,s,s,s,pr

Examples

lanes=4
lanes:turnleft=2
lanes:merge=1
lanes:through=2

Steps, for right-hand traffic:

1. Empty array: ,,,
2. There are no *:location tags.
3. Filling in turn lanes: l,l,,
4. Filling in psv/bus/merge lanes: l,l,,m
5. Filling the rest of lanes with straight direction: l,l,s,m
6. Since we've got one more through lane, adding this direction near the existing one, but not in the merge lane: l,sl,s,m
7. There were turn/through lanes.

The resulting calculated value is l,sl,s,m.

For left-hand traffic the result would be ml,ls,s,s — but it's highly unlikely to have both merge and left turn lanes in the same segment.

lanes=5
lanes:bus=1
lanes:bus:location=2
lanes:merge=2
lanes:merge:location=sides

Steps, again for right-hand traffic:

1. Empty array: ,,,,
2. Place lanes in explicit locations: m,,,p,m
3. There are no turn lanes.
4. There are no special lanes left.
5. Through lanes: m,s,s,p,m
6. No extra through lanes.
7. Let's assume there's a right turn ahead: m,s,s,pr,mr.

For a left-hand drive, the result would be m,p,s,s,mr.

Routing relation

Connecting lanes with ways they lead to is possible only with relations. Also, sometimes it is hard or not possible to determine, which connected way is 'through' direction. For those cases, the relation is introduced. It is extended restriction relation, so all auxiliary tags are the same.

Key	Value	Description
type	lane_restriction	Marks that this is lane restriction relation.
lane	numbers	Semicolon-separated numbers of lanes from the outer side.
lane:to	numbers	Numbers of lanes in the to way. Optional, defaults are stated in the Highway Code.
restriction / except / day_on / etc.	see restriction relation

Members are also the same as in restriction relation. The idea is that lane restrictions do not differ from regular restrictions (are marked with the same arrows), but are different for each lane. It's imperative to use restriction=only_straight_on for through-only lanes.

Examples

There are four lanes, two rightmost lanes lead to different ramps. Tags are obvious:

• Way A: lanes=4, lanes:turnright=2
• Way B: lanes=2
• Ways C and D: lanes=1

How to state which turnlane leads to which ramp? Only with relations.

First relation:

• Tags: type=lane_restriction, restriction=only_right_turn, lane=2
• Members: from=Way A, via=Node n, to=Way C

Second relation:

• Tags: type=lane_restriction, restriction=only_right_turn, lane=1
• Members: from=Way A, via=Node n, to=Way D

Third, optional relation:

• Tags: type=lane_restriction, restriction=only_straight_on, lane=3;4
• Members: from=Way A, via=Node n, to=Way B

If the ramps are separated (and the distance is big enough), the relation is not needed: everything would be obvious from the tags:

• Way A: lanes=4, lanes:turnright=1
• Way E: lanes=3, lanes:turnright=1
• Other ways have the same tags as in previous example.

When the distance is too small, it can be done with above mentioned relations, but the first relation's 'via' member would be Way E.

If all those road segments are have equal highway values, no names or refs, it is nearly impossible to determine, which direction is the "through" one. Of course, in this case right turn might give it up, but consider a left turn in a 100 meters further, so there would be both left and right turn lanes.

To tell the router which way is through, there must be a relation that gives roles to those ways. In this case, it would be restriction=only_straight_on, lane=2 (for right-hand traffic) and with forward-left way as a 'to' member. In the imaginary more complex case, the small segment between intersections would be the 'to' member of that relation, while leftmost lane could still be considered turn lane on both segments.

Change log

 7.10: Simplified lanes:directions algorithm
 7.10: lanes:directions now uses comma separator instead of semicolon
 7.10: lane:to for lane_restriction relation
10.10: Got rid of lanes:directions in favor of lanes:*:location
10.10: Reworked lane building algorithm with regard to the new tags
 9.01: Removed lanes:hgv
 9.01: Voting is opened
16.01: Wrote a FAQ page

Comments

Please leave your comments and questions on the Talk Page.

Voting

Please vote now, using {{vote|yes}} or {{vote|no}} and sign with -- ~~~~ .

• I approve this proposal. --Zverik 19:12, 9 January 2012 (UTC)
• I approve this proposal.--Iav 19:37, 9 January 2012 (UTC)
• I oppose this proposal. The more global key lanes=* should no be misused for such locals purposes. Use a key like lanes:total=* instead. -- Adjuva 20:20, 9 January 2012 (UTC)
• I approve this proposal. Anything that brings us away from mapping lanes separately is great - lets hope editors make it simple in future to use the scheme!--Extremecarver 00:51, 10 January 2012 (UTC)
• I approve this proposal.--Magol 08:37, 10 January 2012 (UTC)

• I abstain from this proposal. The proposal appears to be a dead end conceptually, there is no clear "upgrade path" to more detailled lane mapping. --Tordanik 17:55, 10 January 2012 (UTC)
• I oppose this proposal. Alternative approaches based on value sequences (such as this idea) are much more promising; I don't want this proposal to be accepted before that variant has been discussed. --Tordanik 18:57, 21 January 2012 (UTC)
• I oppose this proposal. I believe that the most important reason to map lanes is to know which lane to take if I want to end up on a certain road after the junction. This proposal does not seem to fulfil that and that relations are the way to go (this or another) --LM 1 20:06, 10 January 2012 (UTC)
• I approve this proposal. Scondo 15:55, 14 January 2012 (UTC)
• I oppose this proposal. Martijn van Exel 17:11, 14 January 2012 (UTC) As mentioned on the tagging discussion list, this proposal does not accommodate for the very common center turn lanes in the US.
• I approve this proposal. b166er 14:03, 15 January 2012 (UTC)
• I oppose this proposal. --R-michael 19:04, 15 January 2012 (UTC)
• I approve this proposal. This is much better than separate lane mapping. A lot less effort and very readable. -- Imagic 19:22, 15 January 2012 (UTC)
• I approve this proposal. -- Sadless74 03:56, 16 January 2012 (UTC)
• I approve this proposal. --railrun 12:50, 16 January 2012 (UTC)
• I approve this proposal. Much better than separate spurmapping --chris66 13:08, 16 January 2012 (UTC)
• I oppose this proposal. I'd really prefer mapping lanes seperately, no unmanagable tag chaos that has no possibility of refinement --Errt 15:40, 16 January 2012 (UTC)
• I oppose this proposal. It's to complex for normal Mappers. I fear all the mapping-faults. Updating these constructions will be horror.--Hurdygurdyman 08:40, 17 January 2012 (UTC)
• I oppose this proposal. bicycle lanes are missing; also, pavement/sidewalks and barriers like guard rails, grass strips or tree rows should be considered; also tram tracks (separated or not; "Stuttgarter Schwellen") should be considered /al 09:22, 17 January 2012 (UTC)
• I oppose this proposal. --BorisC 10:13, 17 January 2012 (UTC) Non intuitive tagging, will lead to chaos since users will not understand the scheme. Also completely ignorant of bicycle lanes. Not expandable. Bad idea!
• I approve this proposal. -- Texamus 14:03, 17 January 2012 (UTC)
• I oppose this proposal. Confusing and complex tagging, not likely to be used much. Furthermore as already mentioned it does not accomodate many common situations, like center turn lanes. polderrunner 18:52, 17 January 2012 (UTC). Edit: See Talk:Proposed_features/Turn_Lanes#Too_many_problems for more reasons and a new proposal.
• I oppose this proposal. This proposal is much too complex and will not be understood by more than 50% of the mappers. -- WalterSchloegl 21:46, 17 January 2012 (UTC)
• I approve this proposal. -- Species 07:31, 18 January 2012 (UTC)
• I am undecided about this proposal. As much as I think this is much needed and would be good for routing apps, I feel this is so complicated that it would be completely necessary with the aid of plugins to be able to tag this correctly. --Skippern 08:09, 18 January 2012 (UTC)
• I approve this proposal. Rather clear scheme that helps to avoid additional geometry for describing lanes and it doesn't conflict with existing *lanes* tag -- Diomas 13:20, 18 January 2012 (UTC)
• I approve this proposal. Good expandable scheme, 0 relations. --Hind 11:32, 18 January 2012 (UTC)
• I approve this proposal. but the problem of US center turn lanes must be solved. Also, things like tram lines, bicycle lanes going into the middle of other lanes, and possibly hard lane separators would be good to get included into the scheme at some point (sorry, makes it even more complex) Robert Kaiser
• I oppose this proposal. This proposal is rather complex Wowik 14:17, 18 January 2012 (UTC)
• I approve this proposal. Scheme might be complex, but that goes for multipolygons, too: If a mapper finds it too complicated, than he won't use it - and somebody else will add the missing info! Center turn lanes and more can be added later or in new proposal. -- Seoman 14:46, 18 January 2012 (UTC)
• I oppose this proposal. The turnlanes plugin is realy useable and easy, where is the difference between these both? Plugin that I mean https://wiki.openstreetmap.org/wiki/Relations/Proposed/turn_lanes -- GandalfTheWhite 19:44, 18 January 2012 (UTC) .
• I oppose this proposal. too complex and too easy to destroy/damage imho -- SKald 22:33, 18 January 2012 (UTC)
• I oppose this proposal. This may be better than other proposals, but still has too many "holes" (bicycle lanes, lane separations, lane splits and merges, etc.), and it still depends on relations. I have some ideas for a more general, concise, and expandible tagging scheme. --Fkv 17:15, 19 January 2012 (UTC)
• I approve this proposal. -- AShadowR 01:37, 20 January 2012 (UTC)
• I oppose this proposal. Too verbose, too fragile. Tagging requires knowledge of the conventions (cf. #Number_of_Lanes), all lane_… tags highly depend on each other. No need for a overhasty decision. No interest or not possible to integrate missing aspects (center turn lane, bicycle lane). – IMHO, the better way: keep it simple, have one tag like in #Building_lane_directions (see Proposed_features/Lane_group, also [1] and [2] from talk-at (in German)) -- Simon04 12:09, 20 January 2012 (UTC)
• I am undecided about this proposal. -- I agree with what Skippern wrote above. Al3xius 19:50, 20 January 2012 (UTC)
• I approve this proposal. -- Dmitry Terentiev 20:46, 21 January 2012 (UTC)
• I oppose this proposal. --Hetzi 09:08, 22 January 2012 (UTC)
• I oppose this proposal. too complex for average lane arrangement, features missing (eg. bicycle lane) -- Almich 16:33, 23 January 2012 (UTC)
• I oppose this proposal. I find it unnecessarily complicated, Why not just listing the lanes as in Proposed features/Lane group -- A uller 10:12, 25 January 2012 (UTC)
• I oppose this proposal. Too complex and fragile, unclear because it doesn't graphically represent the lanes in the tags - you have to mentally construct them according to a fairly arbitrary set of rules, and much is implicit. They'd be difficult to write, and difficult to read. Walter Schlögl's notation is vastly clearer. --achadwick 12:11, 27 January 2012 (UTC)
• I oppose this proposal. It is clearly visible that a lot of time has been in invested in a carefully thought out proposal. Finally I oppose because the number of implicit rules is too high, making it hard for casual mappers to map junctions or find errors in existing tags if they don't map every day. --Martinq 19:49, 31 January 2012 (UTC)
• I would look at the usability of each tag in this proposal. Yet again we find that value of the proposal process is in the discussion and problems solved thereby. The basic tags :turnleft etc. are intuitive and deserve to be used where ever they provide information that is not unambiguous from the way layout. Alv 20:58, 31 January 2012 (UTC)

Voting has ended. 18 users approved, 21 opposed, 2 were undecided. The proposal was deemed too complex and needs improving and simplifying.

See Also

• Frequently Asked Questions
• lanes=* and its talk page
• lanes:psv=*
• cycleway=*
• highway=lane
• Relation:restriction
• Proposed features/lane directions
• Proposed features/lane:x:direction
• Proposed features/lane and lane group
• Proposed features/Lanes as Relations
• Proposed features/Lanes ex
• Relations/Proposed/turn lanes
• Relations/Proposed/Lane
• User:Ömmes/Wayparts
• Dispute in tagging@
• "Lane Connections Tutorial" in MapSource Product Creator documentation

In Russian:

• User:Zverik/Исследование turnlanes — a study for this proposal
• Discussion in Belarus forum, especially vvk000's proposal
• Discussion in Russian forum
• Discussion in ProGorod software forum, Mi81's proposal

/tt>

Second relation:

• Tags: type=lane_restriction, restriction=only_right_turn, lane=1
• Members:

tt>to /tt>