Talk:Key:turn

Hook turns

(The following was copied from the discussion page of the proposal)

Turn key world-wide: Should hook turns (see wikipedia:Hook_turn), where you turn left on/via the right-most lane (right hand traffic, see illustration), be tagged with turn=...|left;right or with a dedicated value like turn=...|hook_turn;right? In my opinion it would be more consistent to use a separate value hook_turn, because the hook turns are labelled different (have dedicated road signs and/or markings other than ordinary 'left' or 'right') and also require different behaviour.--Martinq 10:59, 5 March 2012 (UTC)

If different markings are used, then a different value should be used. I'm thinking of hook_right and hook_left. Although the direction is obvious (if you are on the leftmost lane this will be a right-hook and vice versa) I think providing that information is preferable. --Imagic 12:36, 5 March 2012 (UTC)

Not sure - hook turns are always left on right-hand traffic. We also do not write reverse_left or reverse_right for a u-turn, because they are always to the left on right-hand traffic.

Hook turns are indicated by signposts, lane markings (at the position where the cars should wait before crossing), flashing lights or any combination. They are still not very frequent but getting more popular. In Europe you find this concept on/for bicycle (lanes) (see below), but I don't know exactly the legal implications...

--Martinq 23:00, 5 March 2012 (UTC)

Ok - you got me thinking there. I needed a while to find out why my intuition told me, that we need the direction included. The difference between u-turns and hooks is that in case of u-turns we definitively know the direction we go/drive after the u-turn. Now think about a hook turn. Of course we do know where the hook will lead, if and only if we know on what side of the carriageway we are. And this "if" is the difference. In simple situations this could be determined easily. But now think about a junction with a lot of lanes in each direction mixing individual traffic, psv, bicycles and trams. Can you still determine easily the direction a hook will lead us? --Imagic 07:30, 6 March 2012 (UTC)

Valid point. Yes, I also see the difference now. The 'connectivitity' for reverse can be determined without knowledge about left-hand or right-hand traffic. As long as there is no solution to the left/right-hand side traffic, I agree with you: hook_left (or the more natural 'left_hook'?) and hook_right (or 'right_hook'?) is better. By the way: It seems that the left/right hook turn is also known as "indirect left/right" and is mentioned often in combination with bicycles, see [here]. --Martinq 08:18, 6 March 2012 (UTC)

In my opinion this is not only a problem of left-/right-hand traffic. Even if we have this information available, it is still very complex to determine the direction of the hook. About the name: lets do some research what is used more often: hook or indirect. --Imagic 10:18, 6 March 2012 (UTC)

I'm preparing a major update of the JOSM style Land and Road Attributes and intend to support hook turns. If there are no better suggestions I'll use the values hook_right and hook_left for this. --Imagic (talk) 12:36, 27 March 2013 (UTC)

Too difficult

I just tried to map crossings with this, and it's too difficult. Even when you're working with one-way roads, it's so hard to not make mistakes against left and right. The rightmost lane can be left on your screen, and you can merge_to_left on that lane, but you can not turn left. This is mostly the problem because the string you type "left|through|through;right" is in the exact opposite order than the lanes you see on your screen. If you have to tag a two-way road, it even gets more complicated. The value given to the key is also very long. It's easy to introduce typos in it, as you can't reuse the entire value for different ways.

I believe splitting tags over the different lanes would be a lot better. Something like my old proposal http://wiki.openstreetmap.org/wiki/Proposed_features/lane:x:direction (although you could as well switch the order and type turn:lane:1, this makes no difference).

For counting lanes, that's simple. Lane 1 is closest to the centre line of the road, and in the forward direction. Lane -1 is closest to the centre of the line and in the opposite direction. If you go further from the centre, you just add to your count (or add negative values to it).

It's also easier to have default values (instead of counting the number of pipes).

In short, I will not use this tagging because it's just too hard. Pardon me, and allow me to use my own schema. (Btw, I have my reasons to not be subscribed to the tagging list any more) --Sanderd17 19:44, 28 July 2012 (BST)

Example photo

(Sorry for the poor photo, but I had to assemble it from several video frames). Photo is of a oneway road, from an intersection towards the traffic signals. There's

• two regular lanes lanes=2,
• roadside parking on the left parking:lane:left=parallel),
• no stopping on the right parking:lane:right=no_stopping
• a cycle lane cycleway=lane
  • in the middle cycleway:lanes=no|lane|no.
  • Dashed lines, so other vehicles may cross it.
• Rightmost lane turns right only lanes:turnright=1 and/or turn:lanes=left;straight|right

Actually this should be turn:lanes=left;through|left;through|right. You have to make sure that the number of lanes-values is consistent. In your example we have three "lanes": two for motorized traffic and one cycle lane (note: the key lanes=* only counts lanes for motorized traffic). Furthermore the value straight was changed during the RFC phase to through based on some feedback. The tag lanes:turnright=1 was rejected, because it was too complex..... (no comment on this)... To get a consistent tagging we should stick now with the turn:lanes=* tags. --Imagic 07:50, 5 October 2012 (BST)

• And a bike box/advanced stop line at the signals; cycleway=asl on the node Alv 18:37, 4 October 2012 (BST)

In my opinion, the position of the cycle lane is preferably not tagged with cycleway:lanes=no|lane|no but rather by using bicycle:lanes=yes|designated|yes. Additionally, it's apparently allowed for cars to cross over the bicycle lane but they should probably not use it as a normal lane, this could be indicated using access:lanes=yes|discouraged|yes.--Biff (talk) 21:36, 29 June 2016 (UTC)

equal lanes merging

I need a key for two lanes merging equal (no one is preferred). It can be found in cities. Hadhuey 11:57, 27 November 2012 (UTC)

Simple: turn:lanes=merge_to_right|merge_to_left --Imagic 12:20, 27 November 2012 (UTC)

Merging without extra markings

The key is said to describe indicated turns and merges. Here most if not all acceleration lanes at the ends of onramps/link roads just end, and you're supposed to know/look ahead and merge (and yield) when their lane starts to get narrower right before it ends. To add turn:lanes=||merge_to_left, or not to add, that is the question. Alv (talk) 09:35, 5 March 2013 (UTC)

The word "indicated" refers to any indication. May it be road markings, signs or even common rules/laws. So I would say: yes, add turn:lanes=||merge_to_left. --Imagic (talk) 13:45, 5 March 2013 (UTC)

Connectivity of lanes

I see a problem with this. There is a good tagging for merging lanes, but no tag for "emerging" lanes (I do not know how to call it better - the place whe new lane starts). In these cases you have to split the way to two and tag the second one with +1 laenes. BUT it has a big problem, because the is no information whether the lane emerges on right or on left, so the navigation can not tell what how to connect former lanes to new ones. These is a placement=* but it explicitely sais, that it doen NOT deal with connectivity and that it should be derived from elsewhere. Personally i like very much Turn lanes relation for mapping crossings and shorted emerging an merging lanes. It comes with veryz usefull plugin for JOSM and gives not only the information about connectivity, but also connectivity in the crossing. Nevermind - my question if how to you handle connectivity using turn=*

Short answer: There is no solution yet - prior discussions haven't resulted in consensus.

Details (if you want to understand why there was no consensus so far): The topic has already been discussed when the :lanes extension (where turn:lanes is one use) has been introduced. In the RFC phase of the ":lanes" proposal, there was attempt to address this issue, see Proposed_features/lanes_General_Extension/ProposalPreVoting#Lane_connectivity. There was a subsequent discussion, see Talk:Proposed_features/lanes_General_Extension#Lanes_starting. Finally, the connectivity-idea was removed prior the voting. The idea of using something like 'extend_on_left' was also discussed.

At this time it was more important to get a solution for lane tagging in general - and not to define a complex solution for everything. Thus I think it was OK to "ignore" this connectivity problem (which is not unsolvable). But maybe it is time now to address the connectivity issue [which is not just an issue for "emerging" lanes, it is also an issue at complex junctions] with a specific proposal.

My personal opinion: 2-3 simple default rules, which cover common cases [this is NOT easy, I tried this before, but failed]. Too many rules make the system prone to errors. Conceptionally [right-handed traffic] it will be something like: If no connectivity is given "(1) If a right-turn-lane starts, the additional lane is to the right" "(2) Otherwise additional lanes add on the left". For the remaining, special cases, the proposed relation could be a solution, with the drawback that they do not work well in current editors with casual mappers. However, no proper alternative has been proposed so far: Nodes do not really work, because they do not have a direction (and on junctions its even worse). Tags on ways may not work well on inverting the direction and/or splits - and on junctions I do not see a simple and robust solution with way-tagging yet.--Martinq (talk) 20:26, 26 May 2013 (UTC)

Variable turn lanes

How to tag variable turn lanes (electronically signed turn lanes, similar to variable speed limits)? For example, there is one at this intersection, when approaching from this direction, in the left-most lane (whenever I have seen that sign it was showing "through;left", but it is, after all, variable). --Abbafei (talk) 04:27, 24 October 2014 (UTC)

I would tag that similar to a variable speed limit: if there is a road with variable speed limit, but the limit never goes above 100, I use maxspeed=100 and maxspeed:variable=yes. Same for turn lanes; in your case: turn:lanes=through;left|..|.. and turn:variable:lanes=yes|no|... . So we collect all possible information. --Imagic (talk) 06:38, 24 October 2014 (UTC)

Sounds good to me. Here is a link to taginfo for this tag turn:variable:lanes=* --Abbafei (talk) 07:08, 10 December 2014 (UTC)

Tagging for intersections of divided roads

Let's say that there's is a divided road (two separate ways for each direction) intersecting with another divided road. Let's say that the approach to the intersection on one of the roads (the green segment) is tagged turn:lanes=left|left|through|through|right. Would the road segment between the two ways of the other road (the yellow segment) be also tagged turn:lanes=left|left|through|through, or should it be not tagged at all? There is no exact indication that this is the lane pattern in the middle segment, and is more of a common understanding. Saiarcot895 (talk) 22:24, 2 January 2015 (UTC)

I would also tag it accordingly, because it was indicated right before the junction. You usually tag a whole road section and not only the small parts, where markings are present. Regarding the junction area itself, we will hopefully come up with some kind of tagging in order to improve rendering and routing. A first idea is this proposal, but this needs some revision. --Imagic (talk) 07:49, 5 January 2015 (UTC)

The markings painted on the road can be very different, I have prepared some examples below. They range from fully drawn lanes, over just tiny crosses to indicate lanes, to completely black "boxes" where the driver carefully has to find her target lane. Very often there are no arrows anymore. Thus I suggest that we accept that the middle segment is not always tagged with turn:lanes, as we should map what we see on the ground. The router could easily assume that they were tagged none|none|none and pick the lane matching originating lane. --Polarbear w (talk) 11:48, 9 January 2015 (UTC)

If you want to make this intersection work correctly in OsmAnd you must tag this yellow fragment as you indicated: turn:lanes=left|left|through|through. I don't know if this is an issue with OsmAnd or it should be regarded as a general principle for this type of intersecetion. Rafmar (talk) 16:44, 28 January 2015 (UTC)

This discussion comes straight from the OsmAnd development. A tagging decision has to be made; so the routers, including OsmAnd, can adjust to it.--Polarbear w (talk) 22:02, 28 January 2015 (UTC)

Do not mistake the key turn=* for a key that provides lane connections! We are working on lane connections right now, just needs a little bit more polishing. --Imagic (talk) 11:02, 29 January 2015 (UTC)

Any progress in the past 5 years? I used to map intersections as an open cross like this but I stopped because it has all sorts of problems. It doesn't reflect reality very well, unless there is actually physical a traffic island in the middle (if there is an island and it happens to be rounded in shape, then the intersection might be best mapped as a roundabout). The lanes in the middle segments are often hard to define. And sidewalks and bike lanes don't connect. Nowadays I choose the smaller of the two roads and squeeze it into a single segment (upgraded to a _link that matches the bigger road's class). The lanes might still be hard to define for the smaller road but at least they can make sense on the bigger road. -- T99 (talk) 04:58, 13 October 2020 (UTC)

Turn lanes and transportation mode

When looking at taginfo, I see that apparently some confusion exists how to tag turn lanes for a specific transport mode. Example: <turn:lanes=|right> + <(turn_lanes_for_bus)=|through;right>. What is the correct format for (turn_lanes_for_bus)? Should it be

1. bus:turn:lanes - indicating an abbreviation for access:bus:turn:lanes, which doesn't work because you can't have "access" and "turn" in the same tag
2. turn:bus:lanes - providing turn information for buses in a per lane format -> this looks good.
3. turn:lanes:bus - providing turn information in a per lane format and then ???

In my opinion, the second option is the most promising one. Any comments? --Biff (talk) 21:22, 29 June 2016 (UTC)

+1. turn:lanes=|right turn:bus:lanes=|through;right seems the most logical. —M!dgard [ talk ] 11:54, 1 July 2016 (UTC)

The follwing is just intended to capture and document some more detailed arguments, based on side discussions:

• (access:)bus:turn:lanes would combine access and turn info into one tag. However, it is typically not a good idea to combine several properties into one tag. -> The first option is probably not a good idea.
• Other tags like "oneway" (see https://wiki.openstreetmap.org/wiki/Key:oneway#Sub_keys_.2F_exceptions) use the mode-of-transport suffix to indicate exceptions for specific modes of transport. Here, the "turn:bus" tag indicates turn info that differs from the general "turn" info. -> This is similar to the second option above.

--Biff (talk) 08:43, 16 November 2016 (UTC)

There seems to be a different tagging scheme under development for this kind of situation: https://wiki.openstreetmap.org/wiki/Berlin/Verkehrswende/Radwege#Radfahrstreifen_in_Mittellage_.2F_Fahrradschleuse_.2F_Fahrradweichen I have no part in either and I am not experienced enough to judge which is more practical, but the Berlin one relies solely on tags with only one ":" in them. --Alfons234 (talk) 07:35, 10 October 2021 (UTC)

Note that this schema is unable to handle a bit more complex cases, see https://wiki.openstreetmap.org/wiki/Talk:Berlin/Verkehrswende/Radwege#turn:bicycle:lanes Mateusz Konieczny (talk) 07:55, 10 October 2021 (UTC)

Yes, I had not completely understood the idea behind turn:bicycle:lanes. So the two are no different schemes, but turn:bicycle:lanes is a necessary addition for rare special complex cases. --Alfons234 (talk) 08:12, 10 October 2021 (UTC)

U-turns from left turn lane

In the US, if there is a lane for turning left and for making U-turns, I think it is marked as a left turn only lane. So if I am using context to add turn info about some lanes without explicit markings as mentioned on the wiki, I should use "left" for those lanes and not "left;reverse", right? Germyb (talk) 06:24, 4 September 2017 (UTC)

I think you are right, because you should tag the indicated turn direction. So you're primarily supposed to tag the marking that you can see on the road. In my experience, u-turning from left turn lanes is also permitted in many other countries - unless explicitly forbidden by a "no u turn" sign, which is then tagged as a turn restriction. --Biff (talk) 07:56, 4 September 2017 (UTC)

turn: without lanes?

@Minh_Nguyen - you have added taginfo boxes for some values I do not understand. What do these keys describe? turn=*, turn:forward=*, turn:backward=* ? It seems they are just mistakes where 'lanes' was forgotten?

Also, what is turn:both_ways=* and turn:lanes:both_ways=* ? Even when both directions have the same value, it would be unambiguous to have separate tags turn:lanes:forward and turn:lanes:backward.

I'd prefer to flag those as tagging mistakes. --Polarbear w (talk) 08:49, 13 October 2017 (UTC)

I'm also surprised by the addition of both_ways. I could imagine this being intended for two-way lanes, but it's not documented on Lanes. That suffix also would need to be properly defined, or it would open a can of worms (e.g. what about two-way cycleways that are off to one side of the road?). So unless I missed this tagging being agreed on somewhere, I don't think it should be listed here.

As for the variants without lanes suffix: The forward/backward suffixes are part of the Lanes tagging schema in this case, not part of the turn key itself, so turn:forward and turn:backward make no sense and should be removed. (And turn by itself, while not wrong, could also be removed as it's already visible from the infobox.) --Tordanik 12:27, 14 October 2017 (UTC)

(Sorry for the delayed response. I wasn't watching this page, and mentioning a user with an @ doesn't ping them automatically.)

:both_ways is for center turn lanes (also known in the U.S. as "two-way left turn lanes"). Center turn lanes differ from ordinary turn lanes in that a single lane serves traffic in both directions, and a driver can turn at any point along the lane (rather than at the end of the lane). turn:lanes:both_ways=* is the best existing option for tagging center turn lanes, far better than the centre_turn_lane=yes tag that had previously been used throughout the U.S. This diary post is one of several places where turn:lanes:both_ways=* has been discussed informally, but you're right that it needs to be documented better. The :both_ways suffix itself was proposed in Proposed features/Suffix both ways.

As I understand it, in general, :lanes is used to distinguish between values that differ from one lane to another. We don't go around tagging maxheight:lanes=*, even though it is possible for height restrictions to differ from one lane to another on the same road (such as when passing under an inclined bridge). So on a one-lane road, turn=* is equivalent to turn:lanes=*. Similarly, turn:backward=* and turn:forward=* could be used on a road with one lane in each direction.

I added these extra taginfo boxes shortly after adding corresponding boxes to Key:change. change:forward=* and change:backward=* aren't all that rare; it stands to reason that turn=* and change=* would have similar variants. Anyways, I'm ambivalent about the :lanes-less variants; they save me typing (since I map turn lanes in iD), but inserting :lanes wouldn't be the end of the world.

 – Minh Nguyễn (talk, contribs) 02:39, 8 February 2018 (UTC)

Contextual assumptions

The following paragraph has been moved over from the main page, where it was introduced on Aug 25, 2016 by Paul_Johnson:

"Note: Due to concerns that turn lanes are infrequently explicitly marked with signposts or pavement markings, and how data consumers are already using this data, it has been suggested that explicitly tagging turn lanes where the turn lane values are assumed by context should also be done. ref: https://lists.openstreetmap.org/pipermail/talk-us/2016-August/016656.html "

While I understand the topic was discussed in the talk-us list, it does not reflect international consensus. In particular it violates the rule of tagging what is on the ground, and not tagging for a particular data consumer, in this case OsmAnd was mentioned frequently in the talk-us list. There were also misconceptions that OsmAnd would "invent lanes" (what was perceived as invented are "fork lanes" in OsmAnd, and I agree that they are hard to distinguish from turn:lanes, see OsmAnd#2919), and OsmAnd does not highlight all 'none' lanes as possible for a right turn.

Thus I cannot agree to the recommendation to tag lanes as "assumed by context". Certainly, if the traffic is guided by solid lines or kerbs in a particular turn, that should be treated as ground indication equivalent to painted or signposted arrows. --Polarbear w (talk) 17:35, 13 October 2017 (UTC)

Gore areas

OMUTCD R3-H8dt

I'm increasingly seeing lane control signs in Ohio that indicate the gore separating turn lanes from through lanes, as if to distinguish this case from the normal case where there's no gore. Here's an example. Gores separating turn lanes sometimes occur on wide arterial roads. I can't find any mention of gores on lane control signs in relevant standards, but maybe there's something provisional that I've missed.

I'm tempted to tag this configuration as turn:lanes=left|none|through|through;right vehicle:lanes=designated|no|designated|designated, but that's sure to throw off routers that attempt to display lane diagrams or incorporate lane counting into voice instructions. (In some cases where the gore is wider than a lane, I've mapped the left turn lanes as a separate link way, but that prevents routers from being able to show the full set of lanes at the intersection.)

 – Minh Nguyễn ^💬 19:09, 30 December 2018 (UTC)

I assume you refer to this: Gore_(road)? I'd be strongly against treating such areas as lanes. You should also not map separate link ways when the lanes are not physically separated. --Polarbear w (talk) 22:40, 30 December 2018 (UTC)

Normally I'd be 100% against treating gore areas as lanes too, but in the cases I'm talking about they're closed lanes, placeholders for turn lanes or through lanes that will eventually be opened once it's possible to go in that direction.

For what it's worth, I do think it's appropriate to map a channelized turn lane as a separate way when the gore area is sufficiently wide (though not in the case I linked to above, which is just a little positive offset). Sometimes they're wider than a typical road, enough that a navigation application might consider the user off-course if the roadway is mapped as a single way but the user is on the leftmost or rightmost lane. Typically, such gore areas are impassable for practical purposes. For example, there may be a gutter for collecting water running down the middle, so the pavement is uneven, and plenty of debris may collect in these areas because they don't benefit from regular street sweeping. The MUTCD (the national road design standard) considers them to be functionally equivalent to a physical separation. Unfortunately I don't have a good example off the top of my head.

 – Minh Nguyễn ^💬 20:23, 3 January 2019 (UTC)

Given that the gore area is often part of lane use signs in Ohio, I think it's appropriate to allow them to be mapped somehow – if not as part of turn:lanes=*, then as a parallel tag, however inconvenient that would be. LeifRasmussen has experimented with editor support for width:dividers=* (and variants thereof) and a lanes unit as an alternative to mapping the gore area as an inaccessible lane, so for now I'm mentioning that as an experimental idea at MUTCD/Ohio/R#R3: Lane Usage and Turns. – Minh Nguyễn ^💬 19:55, 1 January 2021 (UTC)

Unusual arrows

The established tag values cover most of the turn lane arrows I see in the U.S., but once in awhile I see indications that don't map straightforwardly to those values:

• Through skewed to one side [1][2][3][4][5][6]
  • Not to be confused with a slight right [7][8]
• Right-then-left at a staggered intersection [9]
• Turbo roundabout [10][11][12][13][14][15] This is actually a national standard:
  • The dot is meant to dissuade drivers from going clockwise around the roundabout.
  • I use turn:lanes=reverse/left/through/right as usual, though routers tend to drop these tags because they look invalid out of context.

I wonder if it would be a good idea to invent some new turn:lanes=* values for these unusual arrows.

 – Minh Nguyễn ^💬 21:13, 3 January 2019 (UTC)

@Corsa5: I noticed you created turn:lanes=slide_left and turn:lanes=slide_right, though there aren't any examples of it in the OSM database right now. Do you agree that the examples of "Through skewed to one side" above would qualify as "sliding"? I agree that there should be a distinct value for this kind of turn, but maybe through_skewed_left and through_skewed_right would be more accurate descriptions of what it's intended to represent: after all, the driver is supposed to think of the lane as mostly a through lane. – Minh Nguyễn ^💬 22:48, 12 July 2021 (UTC)

• • Sorry, I do not speak English well and might have misunderstood something. If I understand correctly the road sign of another country, then this is an analogue. It doesn't matter to me what it will be called, the main thing is that it should be (besides, now it is almost not listed anywhere and can be created with a new name). My sign means that after the intersection, the driver must shift (shift, slide) one lane to the left or right 123. (Warning: there is an error in the above examples - the "straight" sign is indicated there, but there must be a "slide"). Corsa5 (talk) 10:27, 13 July 2021 (UTC)

I had a look at UK roadsigns and we don't have such a sign in normal use - the closest might be the road narrows on the left/right sign but I'd only expect to see that on a road with one lane in my direction. There are similar signs though during roadworks on motorways. The manoeuvre is explained as "lane moves to the right".So perhaps lane_moves_right (or left)? https://www.gov.uk/government/publications/know-your-traffic-signs TrekClimbing (talk) 05:56, 14 July 2021 (UTC)

My previous comment was about the slide/skew signs.

@TrekClimbing: Ah, the nonstandard skewed signs I've been seeing are probably based on the standard construction sign for lanes moving to the right. The MUTCD just calls them reverse curves, drawing an analogy to S-curves on roads even though they tend to be more slight. I still think it might be helpful to keep "through" in the value somehow, to associate the maneuver with through more than slight_right. – Minh Nguyễn ^💬 18:27, 14 July 2021 (UTC)

Right-then-left at a staggered intersection: we would call this dog-leg right in the UK. TrekClimbing (talk) 06:19, 14 July 2021 (UTC)

Cool, I've heard this term in the U.S. too but never quite knew what it referred to. It probably wouldn't be the most intuitive thing to name a tag value in an international project, but it is concise. – Minh Nguyễn ^💬 18:27, 14 July 2021 (UTC)

Turbo roundabouts: we have but no special signage, just lane indicators. Would this be better tagged on the junction itself (like mini-roundabout)? TrekClimbing (talk) 06:19, 14 July 2021 (UTC)

These are the MUTCD's lane indicator signs for every kind of roundabout, from a tiny traffic-calming roundabout to a full-fledged turbo roundabout with a large monument in the middle. They're distinct from roundabout warning or guide signs. They're considered to be a variant of the standard U-turn/left/through/right signs but with an extra emphasis on moving counterclockwise to avoid mishaps by unfamiliar drivers. [16] – Minh Nguyễn ^💬 18:27, 14 July 2021 (UTC)

Clarification on use of turn:lanes on a bidirectional way

If turn:lanes is used on a bidirectional way, should the number of values separated by | represent the total number of lanes (thus, once lanes:forward number of values are given, the direction of right/left switches as the remaining values are for lanes:backward)?

I ask because the start of this page says that turn without suffix applies for both directions. Meanwhile lanes without suffix specifies the total number of lanes combining both directions. As a combination of the two, it is unclear whether turn:lanes should also combine both directions (a value for every lane), or apply for both directions (a value for half the number of lanes).

I don't intend to tag in this way, it seems to me that :forward/:backward/:both_ways should always be specified for bidirectional ways. However, I'm working on external tools and need to know how to interpret such tagging. --TheEditor101 (talk) 19:24, 29 January 2019 (UTC)

Like you, I wouldn't use this in my own mapping. And further, certain quotes from the original proposal (in particular, "In the common case of two driving directions we need to use the already existing :forward/:backward extension.") make me believe that turn:lanes without a suffix on bidirectional roads should be treated as a tagging error by tools encountering such data. I wouldn't mind this being made more explicit. --Tordanik 18:11, 1 February 2019 (UTC)

Values for tagging of left turn & through (only) and through & right turn (only)

Just added symbols/pictures for turn & through (only) and through & right turn (only).

What is the favorite value for left turn & through (only) left;through or through;left
What is the favorite value for through & right turn (only) right;through or through;right ?

Value	Description	Road marking example	Signpost example
left;through / through;left	left turn & through (only)
right;through / through;right	through & right turn (only)

--MalgiK (talk) 16:43, 17 July 2020 (UTC)

A national anecdote: Some countries viz Japan (one of the few I'm more familiar with) separate turning arrows for different auxiliary/added queue lanes on approach https://cdn.snsimg.carview.co.jp/minkara/blog/000/033/258/082/33258082/p1.jpg -- Kovposch (talk) 22:25, 17 July 2020 (UTC)

Thanks for response and for showing the japanese example (btw, do you know where it is located in detail & the osm-way-id of this example?). I would tag the first way-segment (which has separated direction arrows / lower picture area) as turn:lane=left;through|through;right. So the same value through;right for the right lane marking, if there would be a painted sign. Or would that be wrong? If not, this example (picture) could be added to the same table line (through;right) column (Road marking example), as a second example picture. --MalgiK (talk) 22:24, 18 July 2020 (UTC)

No idea of the location. They are common all over the country. I didn't mean to disagree. This is a minority afterall. I only want to know if anyone thinks we should distinguish same-lane and upcoming-lane movements. The vast majority of countries don't, and we are following marked turning arrows.

Found some data regarding distribution of the potential different values, see table below. It seems method left;through for & through;right for has many more uses. So should the lower variants (through;left for & right;through; for ) be declared as deprecated? If it is for interest could anybody with access to a tagging list ask for other opinions on this question? --MalgiK (talk) 22:24, 18 July 2020 (UTC)

left;through	through;left	right;through	through;right
turn:lanes=left;through|through	turn:lanes=through;left|through	turn:lanes:forward=left|right;through	turn:lanes:forward=left|through;right
turn:lanes=left;through|through;right	turn:lanes=through;left|through;right	turn:lanes:backward=left|right;through	turn:lanes:backward=left|through;right
turn:lanes=left;through|right	turn:lanes=through;left|right	turn:lanes=left;through|right;through	turn:lanes=left;through|through;right
turn:lanes=left;through	turn:lanes=through;left	turn:lanes=left|through|right;through	turn:lanes=left|through|through;right

--MalgiK (talk) 18:25, 17 July 2020 (UTC)

"could anybody with access to a tagging list ask for other opinions on this question?" you know they are public? -- Kovposch (talk) 22:15, 17 July 2020 (UTC)

Yes I know it is public, but I never used it (and honestly i don't like mailing-list system). As said, if it is of interest and you are family with such lists, feel free to forward it, or to link it. --MalgiK (talk) 22:24, 18 July 2020 (UTC)

I'm having issues with Nabble, but you may like it, as opposed to email directly, or a newsgroup interface. -- Kovposch (talk) 10:30, 20 July 2020 (UTC)

I know and use Nabble for reading some list sometimes, but i'm not registered (& i don't want) for writing. --MalgiK (talk) 06:33, 24 July 2020 (UTC)

The order may possibly be reversed when taking left turns from right, eg hook turns and jughandle; although this shouldn't be expected in current usage. You could explcitly recommend following the order as marked, but no need to "deprecate" it. -- Kovposch (talk) 22:15, 17 July 2020 (UTC)

I didn't know about and wasn't care for hook turns and jughandle situations, so thanks for bringing these examples up to think about. So far i understand (after reading some information about these situations) it seems it wouldn't be necessary to use one of the more uncommon variants (through;left and right;through) even for hook turns and jughandle, or why do you think so? Do you have a real osm example (osm-object id) by chance for such a situation? --MalgiK (talk) 22:24, 18 July 2020 (UTC)

You're correct here. This concern is true. These are usually signed only, without surface marking. We shouldn't consider them then?

Jughandle: https://mutcd.fhwa.dot.gov/htm/2009r1r2/images/fig2b_08.gif (MUTCD R3-23~26a)

Hooked turn: https://www.vicroads.vic.gov.au/-/media/images/safety-and-road-rules/az-of-road-rules/rightturnfromleftonlysign.ashx?la=en&hash=91FE0AC6EF6BF374F308C2B3F3BE3F36 (VicRoads)

General non-directional, loop turn warning: https://mutcd.fhwa.dot.gov/htm/2009/images/fig2c_01.gif (MUTCD W1-15)

-- Kovposch (talk) 10:30, 20 July 2020 (UTC)

Btw, I found a real world hook turn example, see mapillary-here and mapillary-here. For these cases there is a signpost some meters before, there are no lane markings at the beginning, and close at the final stopping line there is a road painted right arrow. So the involved osm-object is e.g. this way and i would probably tag it like lanes=2 & turn:lanes=left;right|through (using 'left' even if there are is no surface marking and no signpost) and for the way-segment behind the first junction node a turn tag like turn:lanes=right|through. --MalgiK (talk) 06:33, 24 July 2020 (UTC)

Clarification of when to end turn lanes

Currently, the documentation says the lanes should run "to the junction or the completion of merge." When I first read it I thought "the junction" might include some of the "off-ramp", but I'm now thinking that's not what's meant. Can I confirm that as soon as a road peels off, the turn signs should stop? If so, could we add "For example, where the indicated way is connected to the tagged way or when the lane count changes." Or some better wording if someone has a suggestion? --TrekClimbing (talk) 20:07, 16 February 2021 (UTC)

@TrekClimbing: Yes, routers expect the turn lane indication to extend until the lane drop but no further. In the case of a complex intersection – an intersection between two dual carriageways that is mapped like a # – I've been extending the turn lane indication into the interior of the intersection, even if there are no lane markings within the intersection, but not everyone seems to be taking the same approach. – Minh Nguyễn ^💬 01:31, 23 March 2021 (UTC)

Yes, that's another good example. So that's a problem of stopping before the maneuver. What I was doing was continuing the left turn tagging where the driver would still be physically turning left on the new way although they had passed the separation, which I now realise I should change. TrekClimbing (talk) 08:15, 23 March 2021 (UTC)

Example road including a lane for turning

I think I was able to piece together how to mark different lanes for two-way road with a turning lane, but I thought it was surprising there wasn't a clear example of this on the wiki page. I just created a crude image in paint. Assume that the OSM way points in the direction of the two lanes (OSM way points downward in the picture).

Five Lane Road with Turning Lane

For this picture I would think to mark it:
highway=*
lanes=5
lanes:backward=3
lanes:forward=2
turn:lanes:backward=left;through;through

Is this correct?

Edit: Clarification IanVG (talk) 02:26, 17 April 2022 (UTC)

I just want to add, that in real life this road I'm looking at, the right-most lane can also turn right at this intersection. IanVG (talk) 02:30, 17 April 2022 (UTC)

"the right-most lane can also turn right at this intersection" - is it marked in any way? Mateusz Konieczny (talk) 05:38, 17 April 2022 (UTC)

H shaped U-turn spots

The H shaped spots where one can U-turn on a divided highway: https://help.openstreetmap.org/questions/37870/how-to-map-u-turn-roads/37871 says leave these untagged but I think that is a shame. Do mention how to treat them. Jidanni (talk) 12:38, 17 July 2023 (UTC)