Proposal talk:Turn lanes (relation)

Opinions

• Looks sound to me. This will handle most junctions I know very well. It will of course be hard to achieve a significant usage 'cause it's quite a bit more complicated than a simple junction, but so are turn restrictions.
• Special cases not covered with this is lanes specific to vehicle types or otherwise restricted access. But a combination with the access=* tag may help here.

Yes, the turnlanes:turns relation could/should be augmented with access=* and related tags. I added it.--Benshu 08:03, 18 March 2011 (UTC)

• As mentioned, this is not sufficient for defining the existence of turn lanes in the first place. If all relations are present, the information is there implicitly, but that's not easily retrievable by parsers/tools. It may also create inconsistencies with the 'lanes' tag of the ways itself.

Fair point; it's mostly about ease of editing. As long as lanes are not mapped as individual ways, I think the proposed relations are a good compromise. I'm not sure why there should be inconsistencies with the lanes tag.--Benshu 08:03, 18 March 2011 (UTC)

• This only defines the lanes leading to the junction. Often there are also lanes leading away from it (which are not part of the road itself, but serve as short 'collection lanes' for the junction.) Again this is about existience, as they play no role in turn restrictions.

Yes, this proposal is somewhat asymmetric. I suppose a similar/unified relation could be used for collection lanes.--

Collector lanes are independent from where you cam and are only a property of the way it self.So there is no need to use relations here and could be adequately represented by splitting the way and having different lanes= tags on each section.

Benshu 08:03, 18 March 2011 (UTC)

• Final questions: Are there any concerns when used in parallel with the old turn_restriction relation? Will this work equally well with junctions with one, two, three or more junction nodes / single/dual carriage ways and more than 4 ways? (I suppose yes, but a small paragraph on the main page would be nice.) Chaos99 07:11, 17 March 2011 (UTC)

One concern with using both the proposed and the turn_restriction relations is that they can contradict each other. However, this can (thoeretically) be detected automatically. W.r.t. dual carriage ways: The more I think about it, the more I think that "via" must be allowed to be one or more ways (analogous to turn_restriction). Right now extra ways are required to describe U-Turns and some other, complex scenarious.--Benshu 08:03, 18 March 2011 (UTC)

• Is it really necessary to have different relations for lane lengths and lane turns? These relations are already fairly complex and you need many per crossing. Splitting the length and turns into separate relations in addition just seem to make this unnecessarily complex. -- Amm 18:36, 4 June 2011 (BST)

Not strictly speaking, but it opens up quite some room for inconsistencies. The lane counts and lengths would be stored redundantly for every allowed turn. As always the problem with redundancy is the possibility for conflicting information. It's not an issue I want anyone to (have to) deal with.--Benshu 16:47, 10 June 2011 (BST)

• I find this overly complicated, the need for multiple relations for an incoming direction is not justified. Why not just have a single relation (per access) and take advantage of the member order: select direction (clockwise or anti-clockwise, perhaps select osm-wide one), repeat from member to indicate the next lane dirs forming something like this: from-via(s)-to-via(s)-to-...-from-... using the members. The length of the lane should be done by splitting the way using lanes tag, in addition some lane:starts/ends=left/right/both is needed to indicate which is extra lane. Ij 12:27, 20 September 2011 (BST)
• I recall about 2 years ago wanting to map turn lanes for several new junctions in my city and was told by a few to not bother. It was messy no matter what way you did it, a massive pain to get right and a nightmare to update if something changed. I see this proposal and plugin fixing one element, i.e. making it easy to do and adding consistency, however I wonder how sustainable it is. I've not been able to use the plugin yet as it seems to be geared to right hand driving but if the plugin allows for easy maintenance of previously mapped junctions then I'd say it is sustainable so rock on! --DaCor (talk) 23:10, 30 July 2015 (UTC)

Geometry in tags?

While I do like the general approach of specifying the turn lanes - it helps satnavs to differenciate between "turn right" and "use the right hand lane (in order to go straight on)" - I feel it's wrong to specify this inside tags ("length"). I would rather suggest to model them with the geometry objects we already have (nodes, ways, relations).

I know specifying lanes individually means increasing the road network complexity by magnitudes - with the added risk of errors in turning restrictions etc. So please view this as a starter for a discussion, I really like lanes to be modelled in OSM. You may wish to link to related lane pages in the main proposal like Users:cmuelle8/multiple way tagging on single geometry.

If it would be possible, e.g. for a renderer, to preprocess the tags containing geometry and translate this to a true vector network, your approach may be favorable (because editing is easier) over the approach to tag each lane individually. -- Kay D 10:04, 17 March 2011 (UTC)

You answered your own question: Ultimately mapping each lane individually is the way to go, but right now this is practical and easy to edit.--Benshu 08:03, 18 March 2011 (UTC)

If you're really going to be gun-ho about using Geometry, how about working in something in the plugin that can automatically measure a distance for you between two nodes. Say, there is already a node on a way for where the turn lane starts, have the plugin provide an option to add in the node ID and it will calculate the distance automatically between the intersection and the node along the way for ya and tag it properly in the relation. At least then if somebody "deletes" the node for where the turn lane starts, you will not break the relation. This might help a few more people accept this idea. -- rickmastfan67 09:02, 22 March 2011 (UTC)

Examples

We need more examples. --Zverik 12:04, 17 March 2011 (UTC)

I will put up some more examples as soon as I can. If you have something specific in mind, please let me know and I will try to address it.--Benshu 08:12, 18 March 2011 (UTC)

What about junctions with separate connectors for right-turning? Judging from the dual carriageway example video, something like this seems to be the way to go forward, but I'm not really quite about that. In reality, the left turn lanes continue right up the junction it self, something which does not seem to be properly represented that way. Or is there any other, better way to do this at the moment? --JanTH 12:27, 10 April 2012 (BST)

Also, why use lengths when we have nodes and ways? --Zverik 12:04, 17 March 2011 (UTC)

You should also have an example for when highways that are 3+ lanes for a long distance and come up to an intersection where one of those three primary lanes turns into turn lane and gets dropped from the highway totally.
An example of this would be on McKnight Road [1] here in the North Hills of Pittsburgh. South of the intersection with Arcadia Dr, it's 3 lanes going Northbound for 4+ Miles. But at the intersection with Arcadia Dr, the right hand lane becomes a dedicated Right Turn Only lane and McKnight Rd continues North of the intersection with just 2 lanes. You need to have an example of when something like this happens. -- rickmastfan67 05:28, 18 March 2011 (UTC)

Additional auxiliary lanes

Might there be a way to expand this into including additional auxiliary lanes like short on/off ramps on Interstates or on other roads? Here's an example of what I'm talking about: [2] Here, McKnight Road (US-19 Truck) Northbound turns into one lane and merges into Perry Highway (US-19) Northbound. And for a short distance, there is a auxiliary lane to allow people time to merge. Expanding the Turn Lanes plugin to work with these as well might be useful. -- rickmastfan67 06:33, 4 April 2011 (BST)

Chaos99 brought these "collection lanes" up as well. One could make the proposal symmetric, encoding turn lanes as well as collection lanes and turns in a from-lane-to-lane fashion rather than a from-lane-to-road fashion. My only concern is whether the extended information will end up being useful. For now I'm gonna leave it as-is, but your point is duly noted. --Benshu 18:12, 4 April 2011 (BST)

Icon Size

I just thought I would post this here for you Benshu. I was just looking at the icon in JOSM and noticed that it was much larger than the other icons in the "toggle buttons" area. Can it be shrunken down to match the other icons size in that area? Thanks. -- rickmastfan67 00:56, 8 June 2011 (BST)

Oh yeah, I originally put that in there as a placeholder and totally forgot about it. (fixed)--Benshu 16:47, 10 June 2011 (BST)

Usage / create relation?

I tried the plug-in, since I like the proposal and the plugin editor looks easy to use. Up to now I wasn't successfull to use it, the plug-in editor only shows light blue background (w/ JOSM 4164). It is not clear to me how to use the plug-in. Toralf 19:18, 25 June 2011 (BST)

• What needs to be selected in JOSM?
• Do I need to create the relations first?
• Can this be done inside the plug-in GUI?

All you need to do (theoretically) is select the junction node (make sure that the lanes tag is set for all roads involved). Then you should be able to add lanes and turn information. I plan to expand on these instructions in the JOSM Wiki soon, however, there are a couple of tickets I want to close first. --Benshu 20:10, 25 June 2011 (BST)

Thank you for the quick respose. Why does the requirement for the lane tag exist? Turning lanes might also exist on "one" lane ways. At the end it might even be helpful to be able to change or create the lane tag from within the plug-in editor. Toralf 23:10, 25 June 2011 (BST)

You are right that the assumption of one lane would work, however, if someone is tagging the (turn) lane information anyways, it does not hurt to explicitly provide this information. It does not take a lot of time. ;) You are right though, setting the lane tag should be made possible with the plugin itself.--Benshu 01:05, 26 June 2011 (BST)

I used the plug-in to create two junctions for tests. These are my findings/thoughts: Toralf 02:41, 30 June 2011 (BST)

• I like the concept of this proposal, it allows to add a lot more detail and precise turn directions without overloading the underlying geometry (no need to model every lane with a way)
• the editor of the plug-in is intuitive and eases the definition
• 16 relations were created per junction. IMHO this is way too much. Is there a way to combine them to one or two relations? One possible solution would be to number the ways in single relation (in a junction of two double carriageways it would be 12 ways) and specify for each way number the specific data (length and allowed turn for each lane) in multiple keys (e.g. way:1:length:right=20;18 and way:3:turn:-1=1;2;3 as an ordered list of way IDs). I do not know how this influences a parser.
• splitting a way that belongs to a turnlines relation, doubles the way in the role from/via/to in the turnlines relation, which causes an error. The above proposal would allow to have a set of ways as long as they share one ID in the relation.
• when a turnline is defined on one end of a way the plug-in doesn't allow to define another on the other end
• but it is possible to define turnlines at both ends of a way when both junctions are defined simultaneously, but then the way doesn't show the turn lines in the editor. They only show up when on end is selected. I guess this is due to the dual carriageway mode of the plug-in.
• since in the US a lot of turn lines are used on larger roads these roads would get spitted in OSM at nearly every junction and side road if turnlines are used. Is there a way to avoid splitting of ways?

Answer: No, on the talk page of Relation:restriction splitting of ways is discussed; without splitting it is not possible to specify from which side the junction is approached. Toralf 04:24, 30 June 2011 (BST)

Improvements that came to my mind, while using (for later once this proposal gets approved) Toralf 02:41, 30 June 2011 (BST)

• instead of the blue background a picture from a WMS Server would help to guess the length of a turn line
• splitting of ways could be performed within plug-in

no need for relations if all directions are possible

In OSM the default is that all turns are possible/allowed if not stated differently. Why do we need to add connections if all directions are possible ?--Skyper 17:50, 28 June 2011 (BST)

One purpose is to specify from which lane the turn is allowed. In my town are roads with 3 lanes per direction and two extra turn lanes. Thus this extra info is helpful for guidance. Toralf 03:25, 30 June 2011 (BST)

Additionally this info can be used by a renderer to draw a more precise representation of the junction Toralf 03:25, 30 June 2011 (BST)

I was not taking about extra turn lanes, but about the defaults and extra, unneeded work/data. Are all turns allowed, if nothing is described or is the default none ? Think about a intersection with only one extra right lane but you are allowed to turn in all directions from all sides, accept the extra turn lane. I hope I do not have to map all connections, but I am not sure about it.--Skyper 17:08, 30 June 2011 (BST)

"Anything goes" is a sensible assumption. At bigger junctions one can get more sophisticated and guess the layout (e.g. not all 3 lanes allow a left turn). However, since -- at this point -- not all junctions are tagged, assumptions have to be made anyways. These will carry over into a world were some junctions (hopefully all bigger ones) are tagged. Or simply put: No, I don't think you should have to tag all intersections.

I would put this into the same bracket as oneway tagging i.e. you only use this where its applicable --DaCor (talk) 23:05, 30 July 2015 (UTC)

There are often places where we don't need to add any turnlanes relations at all, or need to define just a few turns to make the other lanes in the intersection unambigous. I've tried to collect some examples here:

case	visualization	relations needed	comment
00a		no	Three lanes splits to 1+2: one-to-one mapping is unambigous.
00b		no	Three lanes splits to 1+2: one-to-one mapping is unambigous.
01a		no	From the north, only the rightmost lane is sane for turning right. Can you drive straight on both lanes, I'd say you can unless a relation exists.
02a		yes, one	The previous intersection as it could exist: given the one turnlane relation, it's apparent that arriving from the north only that left lane allows driving straight, and therefore the right lane only allows turning right. Does that forbid the single lane road users (approaching from the east) from turning south? IMO no, there would be a turn_restriction relation in that case.
02b		yes, one	Similar concept as above. It's obvious or at least expected, that from the south all three lanes allow driving straight. From the east, how is one to know, without a relation, that the left lane only allows going straight, when there's three lanes and the righthand lane users only use one of them? In practice, though, routers would say "take right lane" anyway.
02c			Once more a similar case. From the west, can you turn right from the left lane? You could be thorough and add one turn relation, as above, to exclude the left lane.
03a			Even more lanes. Without any relations, we could deduce only that From the north, the rightmost lane certainly goes south. From the north, the leftmost lane certainly goes east. From the north, the center lane likely goes south. Does it allow turning? Common sense says "probably not". From the west, the two left lanes must go straight, because at most two right hand lanes can turn right. From the west, we don't know what happens to the lane 2nd from right. With one relation, as pictured, we know that From the west, all lanes except the rightmost must go straight.
03b			Continuation from the previous line (03a): With one more relation we can express that the two rightmost lanes from the north go south. That might not forbid turning left from the center lane, though - compare with case 04b below
03c			Continuation from the previous line (03b): Replacing the second relation with a turnlane relation stating "from the north only the left lane turns left", it's deducible that the remaining two lanes go south.
04a			You can only deduce for certain that northbound the right hand lane allows turning, and the other three lanes must go straight. Without any relations one could assume that the rightmost lane allows both straight and turn right.
04b			You can only deduce for certain that northbound the right hand lane allows turning and the left lane goes straight. With one relation it's irrefutable that the middle lane doesn't turn right, like it could. In practice you could assume that in addition to that, all three lanes from south go straight.
04c			If you express it this way, logic says you can turn right from the rightmost lane (northbound), and because it's explicitly stated that the rightmost lane allows going straight, you can't turn from the middle lane.
03

Some open points remain. In some cases it could be important to know exactly which lanes go straight (03a above), if the next intersection is very close and you'd like to be in the correct lane already at "this one". Alv 16:35, 22 September 2011 (BST)

Dual carriageways / Roundabout

I can see why you proposal is working like it is right now, but I am not happy how it works with two dual carriageways:

1. The lane information for the four middle sections is missing.
2. I know many intersections which can be used as roundabouts (you can always take a left turn). There exists no extra turn for u-turns but after a left turn you can use several lanes in different directions. Have a look at http://www.openstreetmap.org/?lat=47.9904806613922&lon=7.84475594758987&zoom=18. Right now there are all turn lanes mapped separately.
   

Maybe we need to split these kind of intersections in four or even more small intersections.--Skyper 17:50, 28 June 2011 (BST)

Your example is certainly an interesting case. I have doubts whether a reasonable proposal can exist which gracefully handles it while being sane enough to be useful. You are correct however -- with the posed proposal one needs to model it as multiple intersections (and I would argue that they really are multiple intersections). At least to a degree this also renders your first point moot: There are no lanes on the intersection.. well, kinda. :) --Benshu 22:47, 28 June 2011 (BST)

This is definitly only on intersection. There used to be even more connections.--Skyper 15:21, 29 June 2011 (BST)

Newcomer viewpoint

1) In the beginning it's hard to understand, how the problem is solved. Moved plugin example page up, because it's the most straigtforward way to see how this works.

2) May I suggest that this should be merged with turn restrictions plugin? Then this plugin could become easiest way to handle intersections. example: http://www.youtube.com/watch?v=DyHorSJFbyg

3) Is it possible to render lanes "on the fly"?: For example, when i draw line (connect dots), renderer draws arrows before intersection.

Inconsistent with Lanes tag

Isn't this relation inconsistent with the lanes tag. See http://wiki.openstreetmap.org/wiki/Lanes

A turn off lane is considered a lane and as far as I can see this is already actively being used.

vor example a single one way street with a turnofflane at a junction is mappend as lanes=2 just before the junction. The plugin leaves the road at lanes=1 and adds the turnoff lane in the relation.

--Computerfreaked (talk) 12:47, 5 March 2014 (UTC)

It is inconsistent. But one can use it consistently, by not using any of the "+" buttons in the GUI. Then the lane count of the way matches the other areas. However, with the now quite widely spread turn:lanes=* tags etc. these have become mostly (if not totally) superfluous. Alv (talk) 18:26, 5 March 2014 (UTC)

When I used the GUI to map those turn lanes, I experienced some problems in adding lanes which are longer than the way. The maximum lengths of a turn lane was the length of the way - which is sometimes not sufficient.--U715371 (talk) 21:22, 17 September 2014 (UTC)

Just for the record: The tag of the discussed relation is type=turnlanes:lengths, right? --U715371 (talk) 21:22, 17 September 2014 (UTC)

Driving on the left?

Does the turn lanes tool only work for countries which drive on the right?

I would like to tag some junctions in the UK, but the tool adds turning lanes on the 'wrong' side of the road; nor can I make the correct turn connections in the editor.

Am I missing a setting somewhere?

Having the same issue, can't seem to find what I need to change to allow this to work for driving on the left --DaCor (talk) 23:03, 30 July 2015 (UTC)

Added warning

I added a warning ambox since turn:(lanes) is not mentioned and this has seen much wider adoption. Here is an example where this to confusion.--Jojo4u (talk) 20:08, 30 July 2015 (UTC)

Thanks. Although this page uses English words, it completely fails to communicate to me what problem it is supposed to be solving. SomeoneElse (talk) 08:45, 2 October 2021 (UTC)