From OpenStreetMap Wiki
Jump to: navigation, search

Hook turns

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

Left turn via the right-most lane as illustrated by red arrows

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...
Vršovická, cyklopruh, nepřímé odbočení vlevo, V předpolí.jpg CZ-IS10e Návěst doporučeného způsobu odbočení cyklistů vlevo.jpg
--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 (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

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 tagInfo turn:variable:lanes --Abbafei (talk) 07:08, 10 December 2014 (UTC)

Tagging for intersections of divided roads

Turn Lanes tagging.svg

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)

Pl d Vereinten Nationen GPB2014.jpg Landsberger Danziger GPB2014.jpg Landsberger Allee GPB2014.jpg Hohenzollerndamm GPB2014.jpg Frankfurter Tor GPB2014.jpg

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)