Proposal talk:Turn lanes (way)

psv/bus

Time based changes are probably overkill at this point, but just a reminder if you haven't seen it on some other talk page here: we have both bus-only lanes and bus+taxi, aka psv lanes... And they're always allowed for turning (right) if turning right is possible, and some are part day psv, part day psv+goods+hgv, and some are free for all to use at signposted off-peak hours. Alv 22:47, 5 October 2011 (BST)

Thanks, I've updated the proposal: there are lanes:bus now (but no shortcut, since I don't think there can be both bus and psv lanes), and psv lanes are used for turning. As for time based lanes... That is an overkill :) But in the future we might think of something like lanes:directions:times. --Zverik 07:02, 6 October 2011 (BST)

Often plain lanes is unambigous

For example the case of is IMO unambigous with just the plain lanes=* tags. At the node 'n' there's 4 incoming lanes and 4 outgoing lanes. Likewise the next example, but then the Y-split example needs something. Alv 22:47, 5 October 2011 (BST)

Firstly, this proposal is to mark turn lanes, so regardless of ambiguity there should be lanes:turnright=2 when two rightmost lanes are for turning right. Then, that case is unambigous only if every turn lane on the planet disappears after a crossing. Consider this one, that would've looked exactly the same unless there are lane_restriction relations:

--Zverik 06:54, 6 October 2011 (BST)

That has five "outgoing" lanes (2+2+1) vs. four incoming, so it's true that there it's unknown whether the very rightmost lane is "right" or "right + slightly right". All I'm saying is that there are lots of cases where the turn lane does disappear after the crossing. Alv 08:16, 6 October 2011 (BST)

Of course, if this heuristics would be implemented in routing software, then in this case relations are unneccessary. Anyway, mandatory are just lanes:* tags. --Zverik 08:53, 6 October 2011 (BST)

Case: crossing turns

We have a case (with traffic signals, though), where at a y-split (or more like a "|/" split) there's four lanes incoming, but only three outgoing: the rightmost lane is psv only, but crosses the middle lanes to the leftmost lane/the way straight ahead and the middle lanes continue with a slight right turn: 25216602 25216602. Alv 22:47, 5 October 2011 (BST)

Oh wow, I've been there :) Turn lanes arrangement in that is rather simple to tag, but it probably needs a restriction relation for PSVs (with except=bicycle;hgv;motorcar). --Zverik 07:09, 6 October 2011 (BST)

Drop the forward/backward

This proposal is made unnecessarily complex by trying to cater for a situation where there are lanes for different directions on the same way. People will forever be confused by the seemingly similar "forward/through" and "backward/turnback" pairs. If you want to go ahead with this then simplify it by dropping forward/backward completely, and only allowing forward lanes - this means that if you want to tag a way that has several lanes in each direction, you have to split the way in one half for one direction and another half for the other direction, something that will already be the case anyway in most situations where roads are that wide. --Frederik Ramm 07:27, 6 October 2011 (BST)

I would be very happy if there were such recommendation on the lanes=* page: to split a way in two if there are three of more lanes in total. But that would be ideal world, and in reality, for example, this complex intersection is mapped with only three ways (and it's not just a single case, but the same for 99.999% of wide roads). To tell a mapper that he/she must duplicate all ways to map turning lanes is a bit rude. So, :forward/backward is the best of existing options to tag different sides of a road (without using relations), and is supported, for example, by JOSM. Most I can do — put a recommendation on turnlanes page to split ways for complex cases. --Zverik 07:49, 6 October 2011 (BST)

Splitting the way does not help if everything *still* has to carry a "forward:". It only makes things easier if one makes "forward:" the default. Then people have a choice - either split your road in two, or add "forward:" and "backward:" to all the lane descriptions, and I believe the former will be clearer and easier to use. --Frederik Ramm 00:35, 8 October 2011 (BST)

By splitting, I meant making two ways for each direction instead of one. And ":forward" is the default for oneway highways (it probably needs to be stated more clearly). I understand that this is a problem and it doesn't look good - I'll put a recommendation to divide directions, but the tagging scheme should support both cases. --Zverik 06:39, 8 October 2011 (BST)

Lanes as Relations

Hi, I've written down yet another suggestion for lane mapping. And yes, it's based on relations. That's why it's called Lanes as Relations.
It's only a draft - there are no images, no examples - but I think it is worth discussing in the context of this proposal. My reason for suggesting an alternative approach that there are just so many details that cannot be mapped with highway tags (afaics), some of which I've listed on the bottom of my proposal page. I'm interested in your opinion about the relative merits of each approach. --Tordanik 20:39, 9 October 2011 (BST)

Oh wow. Cool! Did you study four other proposals for lanes as relations (1, 2, 3, 4) when you made this one? I've made a list of pros and cons, as well as compared all alternative proposals to mine, but in Russian. To better understand yours, I'd like you to answer:

1. For a 500-mile road with two lanes in each direction, should one make four 500-mile long relations just for "through" lanes, not counting turn lanes?
2. How one can determine where he/she can go from the chosen lane (how lanes from different highways are connected)?
3. On the proposal page, I have several examples. Could you do at least two from each of the three sections with your proposed relations?
4. Does it, in your opinion, pass "Potlatch Test", in other words, can a novice mapper using Potlatch easily identify that the highway has lanes, and add or change those — for example, if a previous mapper miscounted? --Zverik 06:26, 10 October 2011 (BST)

Sorry for the delay, I didn't have much time yesterday. Anyway, I have seen each of the four cited proposals before, except - for some reason - 3 (which starts out similar to my proposal draft, but doesn't really address the relative placement of the lane relations). My replies to your questions:

1. Yes. You can of course decide to start a new relation every now and then to make editing easier. That's what people do for the route relations of very long roads, so I expect it would be done with the lane relations for these roads, too.
2. This is not yet part of the draft, but it would be easily possible to add "to" members to the lane relations.
3. Proposed features/Lanes as Relations/Examples. I've not done examples from the "Routing Relation" section, but I expect this would be covered by reply #2.
4. No. My proposal, like all other proposals that support adding tags to lanes, does not pass the "Potlatch Test".

But let me put it this way: Maybe Potlatch just doesn't pass the Lane Test. I think our current editors' capabilities are too limited, which means that any lane data model is inevitably either very limited or hard to use. The best way out of this dilemma could easily be better tools. If you look at the number of lane-related proposals that bring their own JOSM plugins, I'm certainly not alone with that opinion. --Tordanik 20:27, 12 October 2011 (BST)

1,2. If relations can be split, then to members are needed, because one of two real advantages of the scheme is the relation between lanes in different segments. That also solves the routing task, so lane:turn* are not needed actually.

3. Thanks, I didn't expect you will do those :) Interesting is the last example with non-standard lane arrangement. It seems rather hard to edit: ten relations with 2 to 5 tags and 1 to 3 members each, some of which are relations - just for a 50-meter stretch, ¼ of a crossing. Also, there is a flaw: the value of lane:direction won't get automatically reversed when the way is reversed (the feature already implemented in some editors for :forward/backward suffices). Some proposals solve it by referencing endpoints, and this decision is also flawed, only less so.

4. There is a certain disapproval for relations these times, not only complex, but even ones like multipolygons. With spreading of simple editors like Potlatch 2, the tool to break them all, it is now harder then before to construct a relation-based proposal that don't get hissed off. So, my main task was to minimize the relation count, trying to tag turn lanes without them. And with this, I don't really have to compete with another relation-based proposal that even has a JOSM plugin to support it. But it's that proposal that yours should be compared to, and now "Lanes as Relations" produces at least twice as much relations, is harder to comprehend (because it doesn't contain lane numbers, but other relations as member) and harder to use (because when the relation set is not complete, constructing directions scheme is rather hard). To be usable, it needs a lot of work, to address different perspectives: editing (relations within relations), usage (algorithm to build lane arrangement picture), routing (mostly good now, but needs "to" member relations for each lane) and just browsing (since no editor will allow you to see the whole picture with those relations). It's a good start, but in my opinion, too complex to be approved by the community. --Zverik 16:11, 15 October 2011 (BST)

Thank you for your insightful comments. Designing a data model with the limitations of current editors in mind is clearly not the same task as designing one that could take advantage of a specialized editing tool. Your proposal obviously attempts the former, and it does so quite well. My proposal, on the other hand, would most probably require writing a proof-of-concept JOSM plugin (I did so back then for my first lane proposal) to get anywhere, so the approaches are not fully comparable.

In the interest of full disclosure: I'm looking at this from the perspective of 3D rendering, because that's what my pet programs do. So what I want to know about lanes is ...

• what texture (surface) should I apply to a lane?
• how wide should I draw it?
• are the lane directions physically painted on the lane?
• how do the separators between the lanes look?

Your proposal does, unfortunately, not answer any of these questions. And once we have an established solution, it will be very hard to ever introduce a more powerful one instead. That's why I jumped into this discussion in the first place.

I realize, however, that I currently do not have the time and energy required to push a solution for this problem. Therefore, I wish you good luck for your proposal, but hope that the future OSM community will be flexible enough to extend or replace it with a more powerful concept a few years from now. --Tordanik 22:11, 16 October 2011 (BST)

Maybe 3D features should be applied not to linear features, but to areas, like area:highway? Or, at least, highway=lane. Because there is a lot of information for each lane, trying to jam all of it into tag subgroup is as hard as persuading users to make a lot of relations. Both of those proposals with some modifications could work together with this one. --Zverik 15:26, 17 October 2011 (BST)

Merging left or right lane

Mostly if a lane merges, the most right lane will merge. But in some cases (I know two places like http://maps.google.ch/maps?hl=en&ie=UTF8&ll=47.3505,8.7395&spn=0.0800,0.159302&z=20) the left most lane merges. In such cases it would be usefull to have a "mergeleft".

This is a unusual case, and exactly for such cases I've introduced lanes:directions. Or else we would've end up with psvleft, hgvleft etc — and consider left-hand traffic! But this is a way to solve one of the tag's problems, so I'll keep it in mind, thanks. --Zverik 05:44, 10 October 2011 (BST)

Related to "merge", I would suggest that it's explained a bit, but don't know which section would be the ideal place. Afaict, in this context it means any lane that ends at the last node of the way, i.e. the lane users need to change lanes vs. the concept of link roads merging into the traffic - where one also has to change lanes sometimes soon, although not always. Alv 14:23, 10 October 2011 (BST)

BTW, today I'm removing lanes:directions completely in favor of, for example, lanes:merge:location=left. --Zverik 14:28, 10 October 2011 (BST)

Ambigous tagging

Can somebody tell me how to interpret this example:

lanes=4
lanes:turnleft=1
lanes:through=3
lanes:turnright=1

This can be interpreted either way. The algorithm tells that moving through via the rightmost lane is prohibited, but implementations may differ. So, this is an example of ambigous tagging, made possible because of lanes:through tag. When you think you need it, please reconsider and try to model lanes using just lanes:turn* tags. --Zverik 15:39, 16 January 2012 (UTC)

Unnecessary Proposal

I think this is completely unnecessary. We already have lanes=* to express the magnitude of lanes running parallel on a single osm-way. Then we have a complete *_link set of values for highway=*, like trunk_link, secondary_link, etc. - for smaller links highway=service can be used as well. Then we have Turn restrictions. I claim that any logic in an intersection can be expressed in OSMs data using a combination of these methods. Simply draw turn lanes, which essentially are links, separate if you have good aerial coverage, then determine the INs and OUTs of an intersection. Now, imagine a star topology on the intersection: with Turn restrictions all that's left to define is from what INs a car is able to pass (or not) to an OUT. --Cmuelle8 00:57, 10 October 2011 (BST)

For an example have a look at the data, not the render output, of this area

An argument might be that drawing those lanes separate, which "leave" or "enter" the main highway, is not good practice, because it emphasizes the POINT at which the lane opens. In reality switching lanes is usually allowed for a certain distance, so ideally routing software should know about it - but I think this is a separate issue, since most {primary, secondary, trunk, motorway} links in OSM are already captured as separate ways - and those links essentially have the same problem: they start es lanes, running in separate for a certain distance before leaving the highway AND they are also connected at just a single dot.

IF lane switching is an issue and IF it is desirable to model it as well, a really simple and versatile solution is to simply but those osm-ways relevant into a "lane switching allowed" relation. This has the advantage that it supplements and nicely adds to established practice, without interfering or re-doing "up and healthy" Turn restrictions. --Cmuelle8 01:19, 10 October 2011 (BST)

+1 If we define a numbering system for lanes, e.g. 1 for the almost right lane, we can extend the Turn restrictions (e.g. by lane=<from>;<to>) for defined lanes.

Example:

Way A: oneway=yes lanes=4

Way B: oneway=yes lanes=3

Way C: oneway=yes lanes=1

Node n: shared node between the ways

TURN RESTRICTIONS:

TR1: type=restriction restriction=only_right_turn lane=1;1 Members: from: A via: n to: C

TR2: type=restriction restriction=only_straight_on lane=2-4;1-3 Members: from: A via: n to: B

With a a numbering system we could split or merge lanes with one additional tag within the shared end node of two ways (e.g. lanes:fork=2;2-3).

--bkmap 13 October 2011 (BST)

You do know that you are describing a type=lane_restriction part of the proposal, yes? And it is not enough by itself, since there would be a lot of relations for each crossing, making the database unusable without installing special tools. --Zverik 13:17, 15 October 2011 (BST)

Yes, is known to me. But with your proposal another scheme is introduced for turn restrictions. Because the relation-based turn restrictions scheme is already well-established, I would NOT introduce a new one. There was in the discussion also a proposal to complement the relation for lanes: Allowed directions for each lane. I am against the concurrent use of two basically different schemes. --bkmap 08:45, 17 October 2011 (BST)

The problem of reusing the existing relation is that lane restrictions in that one would be indistinguishable from regular turn restrictions for software that doesn't support lane tag. And there are lots of such programs, including converters to navigation software format and routers. It's like abandoned=* tag: lane=* completely changes meaning of the entire relation. I though of extending restriction relation, but because of those reasons I decided to make a new relation type. --Zverik 09:28, 17 October 2011 (BST)

The point of this proposal is not to change existing routing schemes — in fact, it has nothing to do with "macro"-routing. Some navigation program nowadays allow per-lane routing: telling you which lane to take in advance. That kind of routing is impossible to model with any of approved OSM tagging schemes, and that's what this proposal is aimed at. Also, this is contributing to the recent growth in micromapping proposals: I consider it's no longer enough to map just a minimal number of lanes on the highway, but the exact number for each segment should be stated. For this not to introduce problems, the purpose of additional lanes should be also mapped, so the number of "through" lanes that has been the default before, could still be established. --Zverik 05:57, 10 October 2011 (BST)

Equal merge

Hello, I like your proposal very much because it solves the problem I encountered while mapping.

What about two lanes which merge each other equally? Tag both with "merge"? Example: look at road B3 going westwards before the railway bridge here: [1]

Wow. And if two cars happen to drive in parallel on those lanes, which one would have the priority? I guess, it's only one merge lane with location depending on the priority. --Zverik 15:58, 4 November 2011 (UTC)

There is no priority lane. It's one after another. --Jojo4u 20:43, 4 November 2011 (UTC)

In this case, lanes:merge=2 and lanes:through=2 would describe this arrangement. But in heavy traffic it is a car crash waiting to happen :) --Zverik 06:21, 5 November 2011 (UTC)

case nonstandard bus lane location (turning)

So the end of a motorway_link with four lanes; rightmost for turning right, one straight, one bus lane for turning left and then one regular lane for turning left:

• lanes=4
• lanes:turnright=1
• lanes:through=1
• lanes:turnleft=2
• lanes:bus=1
• lanes:bus:location=3

Given that it's a dual carriage road that the turning vehicles are entering, and therefore obvious that the left turn won't happen at the end of this way (wrong way on a oneway), but at the end of the short bit connecting the carriageways (which in turn has the same tags, except lanes=3, no turnright, and lanes:bus:location=2). Potential for newcomer confusion, but not something example photos won't fix. Alv 22:28, 15 January 2012 (UTC)

Center Turn Lanes

As I just read your FAQ on the subject, most people who have been tagging them (including me) have used the center_turn_lane=yes tag and not count them in the lanes total. lanes:reversible imo wouldn't work since it's a tag normally used for when the lane is truly reversible for normal traffic. The center_turn_lane=yes tag is already in use and gaining approval by people using it.
See: center_turn_lane
So, I would suggest you update the FAQ on this subject. -- rickmastfan67 10:40, 17 January 2012 (UTC)

Thank you, I did. --Zverik 11:12, 17 January 2012 (UTC)

Too many problems

Here are some more detailed reasons why I can't approve this proposal.

• No support for cycle lanes, high-occupancy-vehicle lanes and other special purpose lanes
• No support for two-way lanes (center turn lanes) or reversible-direction lanes
• Clumsy support for bus-lanes
• No support for lane specific restrictions like no-passing to lanes left or right.
• Potentially large number of tags, see example above #case nonstandard bus lane location (turning). And you have to do this for every little piece of highway.
• No good handling of left-turn-and-through lanes or rigth-turn-and-through lanes (ambiguous situations).
• Non-intuitive and you are never sure if you are still missing a tag.

To be honest this proposal is never going to fly even if approved.

However the Proposed_features/Turn_Lanes#Building lane directions section gave me the idea for a different solution to the problem. Why not simply describe the lanes as a list of comma separated values, like l,sl,r,r? I'm currently drafting a new proposal using this idea. Currently it seems to accommodate almost all possible situations and at the same time it is quite simple and easy to use. See Proposed_features/Lane_group. --polderrunner 20:04, 19 January 2012 (UTC)

Actually that was a part of the proposal in the start: a page from history. But almost everybody started pointing at drawbacks of that notation, so I had to rework it into lanes:*:location. I've been following your proposal since it was in your user page. It's good you're not just critisizing, but trying to prove your point, thanks for that. We'll see what will come out of it.

As for your reasons to disapprove, some of them were answered in FAQ, and others rely on tagging scheme being to complex. While I agree that it is not entirely clear from the proposal, an hour of mapping solves all that, as it did already for me and Martin, for example. And also I plan to make tag pages more understandable and cover a lot of usual cases in examples. --Zverik 05:52, 20 January 2012 (UTC)

Well, I think you should have tried to develope that idea a bit further to get rid of all the other tags. Not sure if you refer to an old lane "proposal" (now deleted) on my user page or the lane_group draft which I started building on my user page 3 days ago before creating the official proposal page? The lane_group proposal is still unfinished (draft status). Let see what happens to your proposal. --polderrunner 19:21, 20 January 2012 (UTC)

Case: dual carriage way intersection middle parts

What to tag the short way with the question mark? Given that this is produced with the turnlanes JOSM plugin, the scale is a bit misleading - there's just a few meters wide barrier between the north-south carriage ways (here):

• For traffic approaching from west, one lane is for turning left and the other is for straight through.
• For traffic turning left from north, both lanes are straight through in the context of the left turn

Another note for a case apparent in this intersection; first I was unsure about the value for lanes:turnright on the western approach, but the algorithm rules make it obvious: the turning bus lane must be included in turnright count.

If the northbound traffic (from south) had a different layout for the bus lane, so that the rightmost lane were for turning right and for buses straight through (as in the picture on the left), the tags would changeas shown. Alv 09:16 4 February 2012 27 January 2012 (UTC)

I had a look at the location one day, and turns out that the "if" case was the correct one. The first question about the way marked with a question mark is still unanswered. Alv 11:00, 4 February 2012 (UTC)

access restrictions

maybe i missed it, but the proposal doesn't mention access restrictions for lanes. it rudimentary mentions something like "psv" in some examples, but we know that those restrictions are often far more complicated (with time based restriction,a.s.o.). i'm not saying that this proposal should reinvent and define access restrictions, but it should provide some sort of hook, where a dedicated access scheme can be incorporated later on. for example this one. i suggest a dedicated namespace: access_lanes:<Number of lane>:<further access restrictions>

for example:

• access_lanes:3 = no
• access_lanes:3:psv = yes
• access_lanes:3:resident = yes
• access_lanes:3:delivery = destination

this would also compensate for certain flaws of the turn restriction scheme.

--Flaimo 14:24, 29 January 2012 (UTC)