From OpenStreetMap Wiki
Jump to navigation Jump to 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)

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 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)

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: "

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

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)

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)

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)