Proposal talk:Lanes General Extension

From OpenStreetMap Wiki
Jump to navigation Jump to search

Discussion during the voting should be done here. The discussion above that point is based on the original, complete proposal, which can be found here. The proposal was cut down before the voting and therefore many issues above may not be relevant for the voting.


Please add to the discussion using the Add Topic button above. Keep discussions succinct, try to stay on topic, and mark finished conversations with {{Resolved}} and related templates.

As this page is getting a little long, I'll add some shortcuts here to those topics, which are still in need of some comments.



Extensions in the final proposal

I added a few features/extensions to the proposal which are not necessary. Please vote here what features should be included. Simply sign in the respective cell. Thanks!

Feature Include Exclude
Turnlanes (turn) --Imagic 21:39, 4 February 2012 (UTC)

--Martinq 21:27, 13 February 2012 (UTC)

Median/Center turn and passing lanes (reversible and :bothways) --Imagic 21:39, 4 February 2012 (UTC)
Lane connectivity (relation type=connectivity) --Imagic 21:39, 4 February 2012 (UTC)

--Martinq 21:27, 13 February 2012 (UTC)

Complex layout (direction)

--Martinq 10:18, 20 February 2012 (UTC) (oneway provides similary capabilities)

Instead of signing in every cell, I'll just write here that I'm against all extensions, since these complicate everything too much (but I'm in favor of the core proposal). Some of those can be included later in separate proposals. --Zverik 13:18, 14 February 2012 (UTC)

Choice of the dividing character

Resolved: Rough consensus, I think: let's use vertical bars between lanes, which permits semicolons within lane-specific values. There are some potential breakages with using unusual separators like this; they should be noted and discussed separately. Hope that's fair all round! --achadwick 14:44, 3 February 2012 (UTC)

It seems odd to me that the semicolon carries less weight than the comma in this scheme when the opposite is true in English writing and common programming languages. Could they be reversed? --achadwick 10:59, 3 February 2012 (UTC)

See below though. Both are problematic if opening_hours are to be expressed. --achadwick 11:10, 3 February 2012 (UTC)

The usage of the semicolon in 

 turn:lanes:forward=left|straight|straight;right

is clearly against the current logic since it evaluates to 

 turn:lanes:forward=left|straight|straight
   and
 turn:lanes:forward=right

This problem can be solved by using Plus, which is also more intuitive. 

 turn:lanes:forward=left|straight|straight+right

For the opening hours problem, I'd suggest to use brackets. I dislike special characters in Tags, so IMHO you should revert the descision to replace the comma with the pipe symbol --BorisC 12:58, 3 February 2012 (UTC)

So you're suggesting using both brackets (special characters) and plus signs (special character). That's three separate special characters to one. Strong -1 from me since, IMnshO, a single new special character is cleaner than three. Additionally, one has to be really careful about generative schemes, are you absolutely positive that "+" isn't used elsewhere? In a normal name=* value perhaps? Vertical bar has the distinct advantage of being not commonly used in language. --achadwick 13:07, 3 February 2012 (UTC)
I also don't see any point in using brackets. A single character should be enough to separate lane data. The question is only which one. The vertical bar is rarely used and so a good candidate for this job. --Imagic 13:13, 3 February 2012 (UTC)
Allright. I accept the pipe (I still dislike it, because it is complicated to type on a german keyboard, but that is clearly no point). But I still believe that the semicolon breaks the parsing logic. --BorisC 13:27, 3 February 2012 (UTC)

Another thing to consider is that a semicolon is often the result of an incorrect merge of two lines (maybe because of an accident). Not using it in the tag syntax gives us a simple fault indicator at no cost. BTW Potlach2 displays a warning symbol if a tag contains a semicolon. --BorisC 14:00, 3 February 2012 (UTC)

This proposal accepts the usage of the semi-colon and in no way redefines it. But BorisC has a valid point, that lanes-unaware editors might screw up the lanes tags. I will add this point to the problems section. --Imagic 14:13, 3 February 2012 (UTC)

Semicolons are used on a subset of tags as a top-level separator with the meaning noted above, but it's only a subset, and when a program encounters a semicolon in a value it can't assume it can actually divide up the raw value like that when interpreting it unless its key is specifically known to take values that can be split using semicolons. ref=* is one such tag. name=*, highway=*, and access=* are most definitely not. opening_hours=* is to an extent, but it requires so much additional parsing that splitting is the least of a programmer's trouble over it. The safe assumption to make is that no program can make this assumption for tags it doesn't know about yet.

Minimising the amount of damage a lanes-unaware editor might do when combining ways would be a neat trick if we could manage it. But even if we were to use semicolons as the primary lane divider, a dumb editor joining two or more segments of road would simply make 4,8,16,... - lane ways silently. That wouldn't be an improvement over pipes. Suggestions welcome though!

--achadwick 14:44, 3 February 2012 (UTC)

I guess you got me wrong. I am not (no longer) opposing to the pipe as lane divider, I strongly oppose to the semicolon to be used to concatenate two values for one lane (e.g. straight;right). The plus (or maybe the ampersand) are generally used for that task, while the semicolon is normally used to as seperator for whole values, not subvalues. --BorisC 17:01, 3 February 2012 (UTC)
No, I understand you. Please feel free to mark this as Unresolved if you think there are major issues or better schemes. Links to accepted, widespread schemes where "+" or "&" are used within ";"-separated values would be welcome too; I know of none and there may be good stuff in there we can replicate. Thanks!
I dispute that the semicolon is normally used as a separator for whole values. It is used when there is no alternative for a small subset of tags, chiefly those with syntactically simple values such as ref. Current thinking seems to be that it is rather deprecated for general tagging. You simply can't assume that it will work the way you think it does.
It's pretty much necessary to get around the problem of incompatibility with the defined syntax opening_hours=* and probable values for name=*. This is the core problem, and using U+007C ("|") does that in a way that's fairly simple to type. It's a rare character so it avoids clashes quite well, but there may be other ways of doing this which I haven't thought of. I'm certainly not wedded to any particular notation, character or syntax. Do you have any suggestions?
--achadwick 19:23, 3 February 2012 (UTC)

I think the pipe (|) seperator is ok/nice for seperating lanes! (But it is used in the wiki. I don't know if there is an escape-key, to document it in the wiki-tags. However, this is not a big reason!) I don't like the semi-colon (;) to add a value to a single lane. Better is "comma", "plus" or "and" (, + &) -- MasiMaster 16:33, 4 February 2012 (UTC)

No problem in the wiki: in most situation it simply works, in others (like in tables) you have to escape it using <nowiki>|</nowiki>. --Imagic 13:30, 6 February 2012 (UTC)
OSM is not this wiki. It's a shared map and a database of geographic information, and we choose what we put in it. We shouldn't care whether a choice of syntax would be problematic in MediaWiki; the limitations of MediaWiki should not impose themselves on our map data. --achadwick 12:54, 7 February 2012 (UTC)
As for multiple values within a lane: it's a choice forced on us by supporting opening_hours=* and ref=* both of which are very well established. I guess, think of this as an extra layer on top of that. --achadwick 12:54, 7 February 2012 (UTC)

One thing to consider when using the vertical bar character ("|") is readability. In a proportional sans-serif font such as used in JOSM (or here in the wiki) the "|" character is difficult to distinguish from lowercase 'l' and some other characters. Example "*:lanes=lane1|lane2". This is the reason why I rejected that character in my own proposal. --polderrunner 22:39, 6 February 2012 (UTC)

That's a valid point, but we are running short on alternatives. We need a character, that is seldom (or not at all) used in values and that makes some sense as separator. The good candidates like ; and + are already taken. The vertical bar | that was suggested by achadwick is rarely used and can be interpreted as lane divider line, so in my opinion this character is a compromise we can live with. --Imagic 08:13, 7 February 2012 (UTC)
I'm certainly not committed to any particular character. ! or = or \ or ~ or # or $ are almost as good. I hear you on readability, but that can be worked around by using a better font on the wiki or in JOSM. It may be best to choose something which can easily be typed on a smartphone or tablet softkeyboard though because those are less readily configurable, and | isn't particularly good pn those. It's a shame ! and the natural / are just common enough in name=* and opening_hours=* to break use with those tags). IMO choose something that's rare to start with, visually and/or logically stronger than the semicolon, and then if you find you absolutely must escape certain values let someone else come up with an optional quoting scheme like CSV. --achadwick 12:54, 7 February 2012 (UTC)

(Anyone want to tabulate the possible choices and syntaxes? --achadwick 12:54, 7 February 2012 (UTC))

Possible syntactic ambiguity: opening_hours syntax

Resolved: New syntax works for me --achadwick 12:59, 3 February 2012 (UTC)

The syntax for opening hours makes use of both commas and semicolons. This is going to cause problems if the same characters are to be used for lane divisions.

Perhaps using some new notation for lane divisions which is neither a comma nor a semicolon would avoid this. In opening_hours parlance the semicolon expresses alternatives – distinct spans of time – so perhaps retain it as the alternatives marker within a lane and split lanes with vertical bars ("|"s), maybe?

--achadwick 11:09, 3 February 2012 (UTC)

Good point. I used the comma, because it is quite easy to type, but it doesnt make any difference what character is used. I'll change the character to | and we'll see if this works better. --Imagic 11:21, 3 February 2012 (UTC)
It looks good to me. Vertical bars have a little more visual weight than semicolons, which is nice, and seem to hint at lane divider lines too. --achadwick 12:59, 3 February 2012 (UTC)

Barriers

Resolved: If needed, some way to tag lane dividers can be added in the future. No conflict with the current proposal. --Imagic 13:33, 7 February 2012 (UTC)

One thing that I miss in the proposal, but which should not be too difficult to add, are barriers. I propose to add them as additional lanes, like this: 

lanes=5
barrier:lanes=no|no|median|no|no

Reasonable? Another option would be to define what is between lanes: 

lanes=4
barrier:lanes=nothing|median|nothing

Then the 1st value would be the barrier between 1st and 2nd lane and so on ... -- Skunk 12:46, 3 February 2012 (UTC)

I thought about that too, but left it out of the proposal for two reasons: 1) the proposal should be a short a possible 2) it should be very easy to add afterwards. In my opinion your second option would be the way to go. --Imagic 12:51, 3 February 2012 (UTC)
I would do something like class:dividers=*, width:dividers=*, etc. - these are neither lanes themselves nor tags of the lanes (which should be apparent because the number of dividers is not equal to the number of lanes), so neither of the suggestions above is entirely appropriate. I agree, however, that this can be dealt with in a future proposal. --Tordanik 13:10, 3 February 2012 (UTC)
Just an idea, so I don't forget it. With dividers we could also define what kind of line is between the lanes. -- Skunk 17:16, 3 February 2012 (UTC)

Default values; minimise ambiguity

Resolved: Defaults+exceptions make sense. Human-readable and sorting near the "default" is better. --achadwick 18:18, 6 February 2012 (UTC)

I really like that this is a generative extension to existing tagging. This extension can be applied to any tag; therefore, would it be a good idea to specify some notation or keyword or marker to allow the default value in a particular slot? The default would be any value specified by non-:lanes: tags having the same key after stripping of the :lanes: part, or any defaults established by other means in the absence of any equivalent tags. Permitting that would enhance backwards-compatibility because then you can lane-mark the exceptions to a general rule, meaning that older renderers and data consumers would be able to continue as at present.

Perhaps just leaving the lane's value blank would do: since it has the same meaning as specifying no value for non-:lanes: tags, that's my preferred syntax.

From the programming side, being able to process the keys with as few special cases as possible is important. Programs which are lane-aware will need to recognise that a tag is lane-specific or not, then be able to strip out the :lanes: fragment from the key, then use the resultant key+value to override whatever the defaults for the key are. Open question: is the current syntax unambiguous enough, and could it be simplified for programmers and users alike? I've always liked the fact that Walter's prefixes sort all the lane-specific stuff into one place, and it has some benefits when processing the data because removing a prefix is cleaner than removing an infix. However, if you treat every :lanes: tag as an exceptions to an established rules, perhaps it's better to have them sorted close to the rules they are exceptions to. I'm undecided, slightly favouring the latter for humans, and prefixes for parsing :/

--achadwick 12:55, 3 February 2012 (UTC)

Of course it would be possible to specify default values and override for specific lanes:
  lanes=3
  maxspeed=50
  maxspeed:lanes=80||
This would be like the first example. This is straight forward - I will add an example to the proposal. --Imagic 13:05, 3 February 2012 (UTC)
Concerning syntax: in my opinion the :lanes should not be a prefix, because - as you wrote - then the lanes-tags won't be sorted near to the "main"-tag. This would be less readable for humans and we should give them priority above programs: programs can be rewritten - try this with humans ;-) --Imagic 08:34, 4 February 2012 (UTC)
Works for me! Thanks for the update. --achadwick 18:18, 6 February 2012 (UTC)

Bicycle lane example

Resolved: Question seems to be answered. It seems also to be clear, that in the future we might need some "traffic" key to specify different kind of traffic with just one key (like the access key) --Imagic 13:30, 7 February 2012 (UTC)

In your example for bicycle lanes, you state: 

 lanes=5
 turn:lanes=left|left|straight|straight;right|straight;right
 bicycle:lanes=no|designated|no|no|designated

AFAIK, bicycle=designated itself means that a way is meant for bicycles, but everyone can use ist. Also, bicycle=no means that cyclists must not use it. I think both is not intended in this case. So I would change the last line to: 

 highway=secondary (or whatever applies)
 highway:lanes=|cycleway|||cycleway

or 

 cycleway:lanes=|lane|||lane

I guess the second one is better. -- A uller 14:51, 3 February 2012 (UTC)

Agreed that it's better, but I'm not sure using cycleway values is the right approach after reading the responses below. IMO the value for highway is really an overall total summation of the entire road. Its value shouldn't vary according to the lane, with very few exceptions. --achadwick 16:28, 3 February 2012 (UTC)
Good point. But I'll rather use cycleway:lanes=no|lanes|no|no|lane, because right at the beginning of the proposal I wouldn't want to scare off people with default values ;-) Proposal updated. --Imagic 15:48, 3 February 2012 (UTC)
That's a very questionable approach. If you have a bicycle lane, a bus lane, and a parking lane, then you would logically end up doing this:
 cycleway:lanes=no|lane|no|no|no|lane
 buslane:lanes=no|no|no|no|lane|no
 parking:lanes=lane|no|no|no|no|no
Basically one tag per "lane category". Maybe just inventing a "lane category" tag with values such as "bicycle", "bus", "sidewalk" or "parking" is the better choice, after all? --Tordanik 16:09, 3 February 2012 (UTC)
Thinking about it again, the trouble is you'd have to keep inventing categories/roles for lanes for the entire Cartesian product of access modes, contra/both/with-flow directions, and general usage. Bus-and-bike lane? Taxis too? Contraflow cycle lane? Suicide overtaking lanes? Mandatory and non-mandatory cycle lanes? Contraflow ZIL lanes for officials? So many combinations, so much guff to cram in individual lane values.
Maybe if we restrict roles to really broad usage categories, it'd make sense. Overtaking, parking, turning (-directions) and general usage. The rest can be done with access tags and :lanes suffixes. --achadwick 16:59, 3 February 2012 (UTC)
I used the cycleway:lanes=no|lane|no|no|lane just for the easy examples at the beginning of the proposal. Of course it would be much better to tag this the way A uller described it as:
 lanes=5
 highway=whatever
 highway:lanes=|cycleway||cycleway
This way we specify an default value for highway and overrule for the second and fifth lane. If buses are allowed on the rightmost lane, this could be tagged as:
 lanes=5
 highway=whatever
 highway:lanes=|cycleway||cycleway
 bus:lanes=||||designated
But this is beyond the scope of this proposal. This proposal gives us a way to add properties to lanes. If the existing keys are not good for tagging multi-lane roads, this would be another issue, that has to be resolved somewhere else. I also don't really like the idea of having different values for highway per lane.
The previous example could be made much easier if we use a key which allows us to specify which kind of vehicle is permitted for a specific lane. then you could tag this as:
 lanes=5
 highway=whatever
 somecoolkey:lanes=all|bicycles|all|all|bus;bicycles
Once again: this is beyond this proposal and could be added easily later on. --Imagic 17:52, 3 February 2012 (UTC)
Added a comment in the problem section clarifying this. Thanks for pointing out. --Imagic 08:36, 4 February 2012 (UTC)

Turns on ending bus lanes

Resolved: This is addressed within the restriction relation (extended by :lanes)

A not so uncommon case around here is that a bus lane ends at an intersection, so that the next way does't have lanes:bus=* and both outgoing directions have lanes > 1. (If the next way had a bus lane, there would be no uncertainty, because the only possible next way would be the way after a turn). Traffic rules allow anybody to use a bus lane for turning right. With the syntax I believe a user would end up with

  • lanes=2
  • turn:lanes=straight|straight;right
  • bus:lanes=|designated
  • moped:lanes=|yes
  • motor_vehicle:lanes=yes|???? - yes would allow anybody to drive straight, no would prevent them from turning, both wrong. Compare to cyclists and moped drivers, who may use it also for going straight.

How to tag? Alv 11:39, 4 February 2012 (UTC)

DELETED THIS OBSOLETE COMMENT --Imagic 13:14, 4 February 2012 (UTC)
This can actually by tagged with the restriction relation, extended in the usual way with the :lanes suffix (assuming a road with two lanes):
 type=restriction
 restriction:lanes=|only_right_turn
 except=bus;moped;bicycle
--Imagic 09:07, 6 February 2012 (UTC)
In fact this can happen with bicycle lanes, too. Motorcar drivers are at least here allowed to use them just before turning, unless it's separated by a solid line. Often they are for the last roughly 10 meters, but not always. Alv 20:39, 13 February 2012 (UTC)

Bicycle confusion

Resolved

The proposal has all sort of bicycle specific tags in it and it makes it really hard to understand when to use what.

Currently the proposal includes:

  • cycleway:lanes=no
  • cycleway:lanes=lane
  • cycleway:lanes:forward=yes
  • bicycle:lanes=no
  • bicycle:lanes=designated
  • bicycle:lanes=yes

What is the difference between a "cycleway=lane" and "cycleway=yes"?

Also I think it would make this proposal much easier to understand if it is limited to either cycleway= or bicycle= but not both. I think you could remove the cycleway tags and replace them with the three bicycle ones and still have all the same meanings.

--Ckruetze 10:04, 6 February 2012 (UTC)

Thanks for pointing that out. The problem lies deeper here: those tags (bicycle and cycleway) are already existing. I changed all the examples to always use only the cycleway key. The cycleway=yes was a typo. The extensions :lanes and :forward do not represent different keys - they are just suffixes. --Imagic 10:23, 6 February 2012 (UTC)
Yes, that looks much better. --Ckruetze 22:15, 6 February 2012 (UTC)

Left-hand/Right-hand traffic

IMO it's not something that needs tagging, but a tool to look at the any roundabouts within the same administrative area (and the "flares" of those roundabouts). It would even catch the odd mapping mistake. Alv 10:42, 6 February 2012 (UTC)

This is a little bit controversial. For a router this information is more a nice-to-have than a must-have, because if the information is not available the router e.g. only loses the possibility for penalties on left-turns in case of right-hand traffic and vice-versa, but routing still is possible. A renderer on the other hand is completely lost, because it doesn't know where to render the forward/backward lanes. So I am pretty sure that someone(TM) needs this information. But in my opinion this information can be provided easily somewhere else and therefore need not to be included in this proposal. --Imagic 11:38, 6 February 2012 (UTC)

Lanes starting

There was fancy example imagery captured and yet the given tagging nor the proposal itself addressed the question which way the lanes=3 became lanes=4, ie., which lane started? --Ij 12:55, 6 February 2012 (UTC)

This could be solved with the connectivity-relation, if I read it correctly it should be:
 type=connectivity
 from:lanes=1|2|3
 to:lanes=1|2|3;4
-- A uller 13:08, 6 February 2012 (UTC)
This is correct: if necessary, this can be solved by connectivity. The relation was not used in this example, because it is an example only for the turning lanes and also because - in my opinion - this connection is "obvious" (new lanes are always innermost). The connection from lanes=3 to lanes=2 at first seems to need a connectivity relation, but if you note that the outermost lane is a mergeleft lane, it is also obvious that the outermost two lanes merge to one and continue as the single outermost lane. Should we add some rules for "obvious" connections? --Imagic 13:28, 6 February 2012 (UTC)
While I missed the possibility to connect mid-sections too with connectivity, it does not explain how the markings on the street are done. I.e., whether keeping the lane brings you to the lane 3 or 4. I'm unsure if the preferred option actually means something related, however, this is not Y nor T junction case so by definition it won't apply? -- Ij 12:54, 7 February 2012 (UTC)
You misunderstood the example. It meant, that lane 3 connects to both lanes (3 AND 4), i.e. lane 4 is a "new" lane and a driver can (more or less) choose freely which to follow. This is rather common around my place. The preferred is not related to this.
No, I didn't misunderstand you :-). ...Sure you're allowed to go both but one requires you to execute a lane change while the other does not. Whether you can do that "freely" depends pretty much on the traffic situation though. If one acts too late others might have already taken all available room and you end up to wrong highway (or alternatively disturb the traffic flow by waiting for a slot). I agree that in the most common cases it doesn't matter much, and could default to the expected start pattern but occasionally there are some more fancy lane topologies (I'd also want to have that for completeness purposes: currently it is possible to describe merges, ie., lanes ending accurately but not lanes starting). See e.g.: [1] where two lanes begin left to you both going straight but just following the lanes (nowadays, it used to be different) takes to directly to the motorway. Those two newly appeared lanes may both get filled through the leftmost lane in a rush-hour traffic disallowing you to "freely" enter the second starting lane. Having ability to present such starting of lanes in advance may be useful for lane guidance (and also if somebody wants to do lane rendering one day). -- Ij 09:34, 8 February 2012 (UTC)
What do you mean by "mid-sections"? If you mean the :both lanes: they could be connected using the :both suffix on the from and to keys of the relation. I omitted these, because I thought this wouldn't be relevant. Is there really a need to specify lane connectivity for lanes like median turn lanes? --Imagic 13:23, 7 February 2012 (UTC)
Midsection was just used to refer something not in a crossing but I don't find that particular part too relevant for the actual discussions anyway. -- Ij 09:34, 8 February 2012 (UTC)
The turn key is not for crossings only but for any situation relevant, e.g. acceleration lanes on motorways. --Imagic 12:40, 8 February 2012 (UTC)
I think the obvious connections should add the additional lane to the side where B has turning lane (left, right, reverse), if present in B but not in A. Also, when an example is using such rules it would be worth of note to help the reader. :-) Another rare but non-matching is with a road that has two consecutive merges, first from 4 to 3 and then 3 to 2 (as mergeleft "re-appears" immediately with 3 lanes). -- Ij 12:54, 7 February 2012 (UTC)
I'm not sure if your first example is really obvious: how are the lanes connected if the following way (i.e. B) has turning lanes? I adapted the last rule in the obvious connections. I think it covers your second example now. --Imagic 13:23, 7 February 2012 (UTC)
The second case is covered now but the example fig case is now broken as there lanes reduce due to turning lane departing (so it probably needs additional conditions based on what happens with the other lanes. I suppose some extra condition like: other lanes remain unchanged is also needed). I think I fixed the first case too now by merging two rules together. -- Ij 10:15, 8 February 2012 (UTC)
Let's go a step back and have a look on the overall lane 'connectivity' topic:
  • Lanes at junctions (more than two ways connected to the node): We want to define, in which road and lane a lane ends up.
    • Solution so far: We have defined the key turn, thus we can describe if a lane ends up left, right or is a through lane (and additional grades if more than 3 follow-up roads are possible). 'turn=left' is only a connectivity 'light', it defines the target road but not the target lane(s).
    • The proposal additionally defines the connectivity relation, which allows specification of the target road and target lane(s). For minimizing the number of necessary relations, we have (started?) defined rules for the 'obvious' cases. This way we make the 'turn' tag (or 'connectivity light') powerful enough, because target lanes not defined by the tag are then defined by (implicit) rules.
    • A special case of a "junction" are road merges, e.g. where two motorways join or slip/access roads joint the motorway. Now if a two lane road from the left and a single lane road from the right side merge and continue as a three lane road, the flow of lanes is pretty obvious. After running parallel, lanes may merge downstream. No problem to define this with our proposal. BUT: Our proposal does not cover lane merges with different rights of way, because we only have merge_to_xxx values yet. In my area you have to give way on the slip road (traffic on the other lane has priority). But if two lanes merge on the road, cars from each lane must alternate (no priority for one of the lanes).
Can you give me an example of a situation where a merge lane has to give right? Right now I can't imagine it completely. --Imagic 14:52, 21 February 2012 (UTC)
Most slip roads [[2]] fall into this category (give-way sign!), but you find this situation also on non-motorways especially if (oneway-)roads with higher speed limits merge in sharp angle.--Martinq 16:22, 21 February 2012 (UTC)
My english vocabulary just extended - up to now I called them acceleration lanes. At least now I know what lanes you mean. Before we start thinking about how to solve this within this proposal, we should take a look on how this is solved for ways only up to now. Actually highway=give_way was the only thing I could find. And in my opinion this is not really a solution. In my opinion we should not consider this further, unless a common solution for this has been found. The proposal is very extensible so we shouldn't run into a problem, no matter how to give-way-solution looks like. --Imagic 08:30, 22 February 2012 (UTC)
'Slip road' is a very common term in England (e.g. 'queues on slip road'), but - as far as I understood it - refers more to the road (the 'ramp') that merges/branches - not the lane (an I was refering to the 'merging' roads). I don't think 'acceleration lane' and 'slip road' are interchangeable. Give-way: Yes, the current tagging allows to mark the slip road as give-way - but sadly not the lane where it is really relevent. But I fully agree that we can solve this really minor issue independent from this proposal.--Martinq 09:21, 22 February 2012 (UTC)
  • Removal of lanes without junction/outgoing road at the node: We want to define, which lane disappears.
    • Solution so far: We have defined the values merge_to_left and merge_to_right, also 'loaded' into the turn key. This seems to work. Minor: Priority/give way not covered (see above) and double merges (3->1) - which IMO happens only over a longer section allowing us to split the way.
Are you sure the double merges are not covered by the proposal? How would you interpret something like turn:lanes=|merge_to_left|merge_to_left and the following way only has a single lane? --Imagic 14:52, 21 February 2012 (UTC)
You are right.--Martinq 16:22, 21 February 2012 (UTC)
  • Addition of lanes without junction/in-coming road at the node: This is discussed here. We want to define which lane 'splits' into two lanes and in which lane somebody ends up if 'stayed in lane'.
    • Yet we have just the connectivity relation. The example demonstrates that it is not possible to define whether we end up in lane 4 or 3 if 'we stay in lane'.
My proposal is straight forward: If we can define merge_to_left and merge_to_right, why not extend_on_left if a new lane starts on the left side and 'stay in lane' is on the right, extend_on_right for vice versa [and (maybe) split for cases without clear 'stay in lane' - I'm not sure about this]. turn:lanes=|extend_on_right| from a 3 lane to a 4 lane situation would connect 1->1, 2->2;3 and 3->4 and imply that poeple staying in lane 2 will end up in lane 3.
Side note: For really ugly cases (especially through junctions with rather odd lane connections) we may have to make the connectivity relation more expressive, e.g. from:lanes=1|2|3|4, turn??:lanes=extend_on_right|extend_on_left||merge_to_right, to:lanes=1;2|3;4|5. Hopefully, this example just exists in my weird mind. I'm not sure we should over-complicate our proposal for theoretical cases only.
However, the turn tag gets even more overloaded with 'extend_on_xxx' - and we are back at the discussion about the right name (see topic somewhere below). Now, for the merge_to_xxx values I didn't saw an urgent need and 'turn' was good enough. But if we add more tags, I get slighty more uncomfortable with 'turn' and want to re-open the discussion. I saw following options:
  • Rename to connectivity (other ideas welcome) -> connectivity=left,...,right,...,through,merge_to_left,merge_to_right,extend_on_left,extend_on_right. This would be more generalized than turn, which does not really work well with extend/merge values. Disadvantage: 'connectivity' does not really make clear that lanes without marking/signposts shouldn't be tagged with 'through' or 'through;right'. 'connectivity=left' is not as expressive as 'turn=left'.
  • Separate tags for road connectivity (a.k.a 'turn lanes' a.k.a. 'connectivity light' -> keeping turn=left,...) and (intra?-)lane connectivity. Lane connectivity could be tagged as lane_course (better name required), allowing the values lane_course=merge_to_left,merge_to_right,extend_on_left,extend_on_right. lane_course could be used without :lanes extension if defaults are defined (merge_to_left and extend_on_left always on the right-most lane, and vice versa for the others). Disadvantage: Additional tag if merge/extension and turn lanes are in the same section of the way.
--Martinq 13:42, 21 February 2012 (UTC)
Many thanks for this in-depth analysis. Now I fully agree, that we need some way to specify where lanes are added. I also now support the removal of the merge_XXX values from the turn key and put them together with the extend_to_XXX in a new key. As I also don't have any better name I'll go with the proposed lane_course key. I'll update the proposal and the examples and we will see how it works then. --Imagic 14:59, 21 February 2012 (UTC)
As soon as I started to update the proposal I became aware of some fundamental differences between the extensions of lanes, merge lanes and turn lanes. As described in the proposal, the turn key should only be used if there are markings on the lane. So it is perfectly clear where an osm-way with a turn key should start and where it should end. But how about extended lanes? There are no markings - the lane simply starts. And what about merge lanes without markings on the road? They shouldn't be tagged according to the current proposal.
Funny, I detected the same - but you were faster (and I ran into an edit conflict). Lane extensions have no (pre-leading) markings, in the best case there is a signpost describing the different lanes in the next section, also illustrating the lane split. If put into the way section before (which may have any length, e.g. 1km), I agree, it is 'unnatural' (if another mapper splits this way for any reason, we end up with dead/unnecessary or even misleading tags). I have overlooked this flaw (sorry). Merging lanes are different. They typically have markings/signposts (at least in my area), because a driver must get prepared that the lane ends. It is natural to put the tag on the section from the start of the marking/signpost to the end of the lane.--Martinq 17:15, 21 February 2012 (UTC)
Actually I think this is still the correct way: in the turn key only things you could see on the road should be tagged. Because you put the tag on a way and a way has some extent. So you should only tag something that also has some extent.
But where can we put the information now about extended lanes or unmarked merge lanes? In my opinion it is still the best way to put this in the connectivity relation, for a very simple reason: this relation describes something that happens right at the connection of two ways. And the merging or extending of lanes - without markings - happens exactly there at the connection of the ways.
For pratical reasons (see above) I believe that unmarked merge lanes are rare (at least a sign for merging lanes in xxx meter), just because the drivers need a preparation time (except for slip roads which may require some other tagging anyway). Additional lanes: If something happens on a specific point, puting the information into a node could be an alternative. If section A has 3 lanes and section B has 4 lanes, there is a shared node between the ways that could take the information about extend/merge. I haven't thought it through, I just want to point out the alternative - Yet I don't say it is better.--Martinq 17:15, 21 February 2012 (UTC)
Update: Found the issue with node approach: Because nodes have no direction, :forward and :backward makes no sense. Even if assumed that the direction is identical to the connected ways (if they have the same direction...) --> an editor may correctly handle forward/backward on ways when the direction is changed -- but most probably not on the node. Thus I conclude the node approach would work for a very few cases only. --Martinq 07:13, 22 February 2012 (UTC)
So I suggest the following: use the connectivity relation for unmarked and non-obvious merging and extending lanes. What we are missing right now is the information which is the "straight" lane, after a lane has extended to two or more lanes. I would suggest to put this information in the to key of the relation, simply be putting the "straight" lane first. So if we have a two lane road, which extends to three lanes and lane 1 connects to 1 and 2 in the following way, whereas lane 2 would be the "straight" lane and furthermore lane 2 of the originating way connects to lane 3 of the following way this would result in the following tagging:
 from:lanes=1|2
 to:lanes=2;1|3
I think this solves the problem both for extending and merging lanes. --Imagic 15:44, 21 February 2012 (UTC)
Yes, it solves it. But we both know about the resistance and reservations when it comes to relations. I have the "gut feeling" that a relation equiped with 3 tags is rather inappropriate for a simple merge/extend. Your own words in the beginning of the proposal Relations only where needed: relations are often hard to identify and understand. Going back to the alternative above: Either a relation with three tags - or one tag like lane_course:lanes=extend_on_left| on the shared node between lanes=2 and lanes=3? Once an editor also shows a fancy 'lane course' symbol for the node, I see some advantage when thinking about casual mappers. But it is the mix between node and way, the definition of information for the way on a node that gives me an uncomfortable feeling about this 'node' approach. I would like to hear other opinions. --Martinq 17:15, 21 February 2012 (UTC)
I revoke my node proposal, see explaination above--Martinq 07:13, 22 February 2012 (UTC)
Yes, relations are not widely accepted and the reason is simple: it is much harder to see and interpret them. But the problem stays: you simply can not specify properties involving more than one way/node without a relation. Also my first intuition was to put this information on the connecting node. The problem with that is: a node has no direction. So it is unclear if the node describes the extending lane from way A to way B or the other way around. And as soon as you start to add some way identification 1) it gets ugly and 2) you are rebuilding a relation with tags. So I think there is no other way than to use a relation for this. But is this really a problem in this case? The relation should only be used for non-obvious situations and I guess(!!) with a good rule-set of "obvious connections" we could reduce the need of the relation to a neglect-able number. --Imagic 08:45, 22 February 2012 (UTC)
I agree, let's move on with the relation. I will take a closer look at the current rules, this is the only part of the proposal I haven't scrutinized yet. I am also not fully confident if it is a good idea to express 'stay in lane' by ordering lanes as proposed. It works, it is OK for now - and I will open a new discussion thread if needed. --Martinq 10:01, 22 February 2012 (UTC)

Underscores in keywords

Resolved: Added an underscore to applies_to for consistency

Just a minor point, but it would be far more understandable to English speakers if keywords like the proposed mergeleft, appliesto were instead written with underscores: merge_left, applies_to. It would be more consistent with the rest of OSM.

You wanted a better name for applies[_]to: why not just use access tagging convention keys and Boolean values, e.g. motor_car=yes? The restriction relation is fairly awful and limited; let's not copy that if we don't have to.

--achadwick 16:13, 7 February 2012 (UTC)

Minor, but good point. I will add an underscore to the proposed keys to be consistent with the rest.
Regarding applies_to: see the problems section "Need for new keys". The same reason applies here. --Imagic 20:33, 7 February 2012 (UTC)
Then bothways should be treated the same, i.e. both_ways. --Seoman 13:08, 21 February 2012 (UTC)
Good point. Fixed. --Imagic 14:08, 21 February 2012 (UTC)

Driving direction vs. direction of way

Resolved: I guess this can be closed. Please reopen if necessary.

Quote from achadwick's inline comment on the main page (since I find it strange to discuss there, I'm reposting it here): The exact wording is up to you, but I strongly recommend removing the phrasing "the driving direction of the road" because most roads are bidirectional (you also use the term "revserible" below for lanes, and it's confusing here when applied to ways). Best to define it only in terms of OSM properties like the direction of the Way. ~achadwick

Since this proposal does not want to describe all the lanes in one key/value-pair, but only one pair per direction, it doesn't matter if the roads are bidirectional or not. A bidirectional road would need a xxx:lanes:forward and a xxx:lanes:backward key. Forward and backward are determined by the direction of the OSM-way, but for the order of lanes, I think it's easier to go with the driving direction. If you change the direction of the road, only :forward has to be changed to :backward and vice-versa, the rest remains correct. -- A uller 11:30, 8 February 2012 (UTC)
Duuuh! I never saw that comment. No, definitively not a good idea to discuss in inline comments. I remove the comment from there and add it here completely:

May I suggest the text: """ This is a scheme for recoding facts about individual lanes on a road by reusing existing notation. It is applicable to any existing <key>=<value> tag pair. Lane-specific information can be expressed on a Way by suffixing the key with ":lanes", and dividing the values with the vertical bar character, "|". The values are applicable sequentially from the leftmost lane to the right as seen when looking in the direction of the Way. """

The exact wording is up to you, but I strongly recommend removing the phrasing "the driving direction of the road" because most roads are bidirectional (you also use the term "revserible" below for lanes, and it's confusing here when applied to ways). Best to define it only in terms of OSM properties like the direction of the Way. ~achadwick

I have to agree with A uller and achadwick. Achadwick is right, that the wording "the driving direction of the road" may be misleading. But A uller explained the intension correctly. I will try to rephrase this sentence. Thanks both of you for pointing out! --Imagic 11:54, 8 February 2012 (UTC)

:lanes - suffix or prefix

Resolved: Actually this doesn't seem to be a problem at all, i.e. no-one really cares. If you think about the placement of :left/:right/:forward/:backward it only makes sense to put :lanes at the same place.

I reopen this issue already discussed and closed here, because of a discussion on tagging.

We have (at least) two possibilities to add the lanes extension to the key: either as prefix (i.e. lanes:<key>=<value1>|<value2>) or as suffix (i.e. <key>:lanes=<value1>|<value2>). The proposal works both ways, but we should decide what is the best solution for openstreetmap overall.


Things to achieve:

  • Readability for average mappers
  • Ease of processing for applications


When thinking of mappers, please consider that a lot of mappers have no degree in computer science and we are looking for the best trade-off between ease of mapping and ease of processing.

Please add your Pro argument in short to the following table and explain it below the table.

Prefix/Suffix Pro
Prefix

lanes:<key>=...

* Consistent data format
Suffix

<key>:lanes=...

* Easier to understand for average mappers


Prefix: consistent data format While a suffix would change the meaning of an existing key, a prefix would introduce a new key or namespace, i.e. no collision with current data format. --Imagic 10:17, 9 February 2012 (UTC)


Suffix: Easier to understand for average mappers Editor currently sort the keys in alphabetical order. If a suffix is used, the lanes-key will be sorted right before or after the lane-less-keys. This would be especially helpful when working with default values. --Imagic 10:17, 9 February 2012 (UTC)

Relevance of/relationship to lanes key

Resolved: Consensus that lanes key is not linked with the proposal and not needed for making the proposal 'functional'. But if people like to continue using the 'old' lanes tag in parallel (for example for non-extension aware application or legacy applications), it sufficiently explains "oddities" that can arise for this personal decision of the mappers. --Martinq 10:30, 14 February 2012 (UTC)

The examples often use the key lanes=*, but not fully inline with the current description/usage (for example including the bicycle lanes when counting).

I would prefer a clarification that the value of the lanes key is of no relevance for the interpretation of the lanes extension. For me... 

lanes=3   <-- not 4
cycleway:lanes=no|no|lane|no

...is no contradiction (lanes is not required).

The proposal should emphasize that the lanes-key can remain in its broadly used interpretation as described in lanes=*):

Many ways have not yet been tagged with the total number of lanes at all points, but only with the number of through lanes of a longer section.

Example: A short additional 3rd turn-lane (left) in oneway road with mainly 2 lanes could be validly tagged as: 

lanes=2   <-- street or longer section of the street has 2 lanes
turn:lanes=left|straight|straight;right   <-- temporary 3rd turn-lane

Short additional turn lanes or acceleration lanes as well as special lanes (cycleway?, sidewalk?) don't have to be included in the lanes count.

--Martinq 21:34, 11 February 2012 (UTC)

The lanes=3 was simply a typo - I fixed that. I don't think that people will understand, if the lanes=* tag shows a different number than the number of values for a :lanes key. Also the existing lanes tags may stay untouched as long as noone adds new tags like e.g. for turn lanes. You are of course absolutely correct, that the lanes tag - more or less - is obsolete if using the :lanes extension and could simply be ignored. Any additional comments on this? --Imagic 09:39, 12 February 2012 (UTC)
No, after the fix it's worse. The lanes=* key does - at least based on the description - not include bicycle lanes (or parking lanes, etc). Thus the original lanes=3 was somehow better, because implicitly your example redefines the meaning of lanes tag now.
We agree that lanes is not needed that for a functional lanes extension. But when it is used (and you do that in your examples), it is incorrect to count all lanes of the new lanes extension, because this would change the current meaning.
Thus I requested to clarify the relationship between lanes if used - and the :lanes extension, specifically:
  • usage of lanes is not needed when the extension is used
  • if used, the value of lanes and number of lanes in the :lanes can differ
  • Recommendation to continue using lanes in the current interpretation as number of through lanes of a longer section - therefore excluding temporary turn lanes, accelaration lanes, parking lanes and bicycle lanes.
  • Fix your examples by either removing lanes (because it is not relevant) or illustrate that lanes and number of lanes in extension can differ - and why.
Otherwise people start to set the value in the lanes tag equal to the number lanes in the proposed extension without noticing that this is not following its current definition.
--Martinq 11:14, 12 February 2012 (UTC)
When you split ways to depict the changing lane count, lanes=* should be set accurately. It's just a make-mapping-easy-convention that some start by tagging a longer section with the through lanes count. When the lane count is fixed for the whole length of a osm way, the correct value is that count. Alv 12:42, 12 February 2012 (UTC)
It was not the intention to discuss the lanes tag (has some ambiguities) - and therefore I have deleted the recommendation. But the problem with the bicycle lanes persists. To my best knowledge the bicycle lanes are not included in the lanes tag (not motorized traffic) -- but in some examples of this proposal they are (see the example with lanes=9). --Martinq 13:19, 12 February 2012 (UTC)
Indeed, that =9 doesn't seem consistent. Intuitively, I think a major advantage of this =yes|yes|no description format is (vs. the other lane tagging ideas floating around), that since nobody is yet processing such values, anyone planning to consume them can look out for the "added" bicycle lanes, and given the difference between the plain lanes=* value, they can deduce that at least one such lane is a designated bike lane - and where it/they are located. Alv 14:16, 12 February 2012 (UTC)
I hope, that it was your intention to discuss the lanes tag, because that is why we are here. And it is a valid point. One problem - one more time - we have, is the wiki. In the english wiki it clearly states "motorised traffic". In the german it doesn't. And the english version links to a wikipedia article, where bicycle lanes are explicitly mentioned so in some way it contradicts itself. I myself don't have any problem if we don't link the lanes=* tag with the new :lanes extension. But I am afraid, that it will irritate some people. So what should we do? I think we need a clear definition of lanes=* first! --Imagic 18:13, 12 February 2012 (UTC)
There even isn't a contradiction with the wikipedia article: "traffic lanes ... for motorized traffic" is not "any traffic lane", which in the wikipedia authors context includes bicycle lanes. There's nothing ambigous about the lanes=* tag, there's just incomplete data. Like there's incomplete data on pretty much anything in the osm db. Alv 10:45, 13 February 2012 (UTC)
I recommend to don't link the proposal with the inaccurate lanes=* tag. But explain the issue in your proposal ('clarify'), specifically that the lanes=* has several ambiguities and shortcomings. We are not the first, see also postings here [3]. Consequently the "irritation" cannot be avoided (I was also irritated) - only explained.--Martinq 22:32, 12 February 2012 (UTC)
The current lanes definition is not a make-mapping-easy-convention. It allows maps like Ito lanes map. I don´t want to see a 2-lanes motorway as a 2-3-2-3-2-3-2-3-2-lanes motorway. --Seawolff 23:03, 12 February 2012 (UTC)
Tags on a section of a road (one way) describe that section, not the whole road. You can code your preprocessor to count the minimum. Alv 10:35, 13 February 2012 (UTC)
... nor do I want to see 3 lanes road section as a "2-lanes motorway"... :-) It's just a matter of point of view IMHO. As mentioned already, you can derive the minimum number of lanes for any given longer motorway section. -- Ij 10:41, 13 February 2012 (UTC)
I thought like you first, but changed my mind. In this special case I think that software preprocessing/abstraction of 3-2-3-2-2-3-4-2... is rather easy, also customizable (criteria for a 'longer section') and therefore perferable over a rather subjective human abstraction of the lanes (with different opinions what represents a 'longer section'...).--Martinq 15:17, 13 February 2012 (UTC)
I'm not quite sure I understand you (Martinq) now. What do you suggest now? Linking or no-linking with the lanes tag? --Imagic 15:35, 13 February 2012 (UTC)
My response was only a comment to Seawolff's statement "I don´t want to see a 2-lanes motorway as a 2-3-2-3-2-3-2-3-2-lanes motorway". When you look at my original statements (I have striked out meanwhile), then you see that I have proposed to keep the lanes tag as number of lanes in a longer section in the way Seawolff would prefer it. But meanwhile O think it is OK to set the lanes value precisely in every (small) highway section (e.g. if split for temporary turn lanes) -- but of course fully compliant to the lanes tag description. --> I think we still have an agreement that we don't link the extension with the (old) lanes tag. We also still have the issue around the bicycle lanes: lanes (english version) does not include bicycle lanes while your extension includes them. This will still cause irritations/confusion and therefore clarification (you have already started with) is required. Confusion cleared up? By the way: I will comment your improvements separately. --Martinq 16:01, 13 February 2012 (UTC)
I added some more comments in the problem section and clearly state, that the lanes key will not be redefined, i.e. only includes motorized traffic. I think I already removed all lanes keys from the examples with the bicycle lanes. Where do you think they are still included in the lanes tag? --Imagic 08:08, 14 February 2012 (UTC)
The example with lanes=9 includes two bicycle lanes.--Martinq 08:28, 14 February 2012 (UTC)
Found it. Fixed it. Hated it! This really stinks. I don't think that people will understand this! This makes no sense at all. --Imagic 09:58, 14 February 2012 (UTC)
I like the proposal, but I agree this will cause irritation. For me this proposal is a clear step forward to overcome the limitations and problems of the lanes tag. :lanes is the next step in "evolution" and a solution - not a problem. Because this idea is competing with other ideas, this proposal needs some kind of "marketing"...--Martinq 10:30, 14 February 2012 (UTC)

I removed the lanes tag from some examples and added a note in the problems section. Is everybody happy with that? --Imagic 08:40, 13 February 2012 (UTC)

I think the proposal addresses the topic of this discussion thread now. I see also some consensus within the comments, thus I was brave and marked this topic as "resolved". --Martinq 10:30, 14 February 2012 (UTC)

Marketing

Resolved: Thanks for the tip!

As martinq pointed out above, some "marketing" for this proposal could be done by adding it here: Lane tagging comparison. -- A uller 18:47, 14 February 2012 (UTC)

Thanks for that. Marketing done. --Imagic 09:34, 15 February 2012 (UTC)

turn vs. marking

Resolved: There is a consensus that the name of the 'turn' key is not perfectly describing its intention. No clearly better proposal was found during discussion, thus the 'turn' key was not changed. Reopen the discussion/open a new topic if you think you have a new idea around the turn tag --Martinq 08:32, 21 February 2012 (UTC)

I was thinking: what if we instead of turn specify a new key marking or lane_marking? Because right now the proposed turn key describes markings on the lanes. So why call it "turn"? If we call it lane_marking we could add more markings beside turn lanes. Any remarks? --Imagic 10:25, 15 February 2012 (UTC)

Would that get too easily overloaded (i.e., one'd be needing turn and some other marking at the same point of time)? Or did you mean that turn then becomes a sub-category of the lane_marking? -- Ij 13:47, 15 February 2012 (UTC)
At this point I thought of simply renaming turn to lane_marking. So instead of turn=left you would write lane_marking=left. The reason for this is 1) merge_left/merge_right is not really a turning lane and 2) the key lane_marking could be extended to different lane markings (you couldn't do that with a key named turn without irritations). More than one marking will be separated with a ";" - this is already possible with the proposed tagging, e.g. turn:lanes=through|through;right --Imagic 15:12, 15 February 2012 (UTC)
turn might not be perfect, but "marking" is no improvement unless you really want that markings are mapped. But consider that (often) lanes have no marking, which typically means that the left-most lane allows through+left, the right-most allows through+right. I assume your proposal wants to achieve that a three lane junction without any road markings is mapped like this: turn:lanes=left;through|through|through;right and not lane_marking:lanes=none|none|none.
No, definitively not. If there are no markings, then there shouldn't be the need to tag anything. It is - more or less - the same as with the connectivity relation: only tag non-obvious situations. turn:lanes=left;through|through|through;right is a well-known "default" on junctions without markings, so there shouldn't be the need to tag this. --Imagic 08:55, 16 February 2012 (UTC)
OK, I made a wrong assumption. Obviously your plan is that a junction with 3 lanes without any "markings" intentionally does not need any tag (turn:lanes=|| can be safely omitted). Your current description in the proposal does not explain this intention and/or (and that's a valid point you have made!) the lane turn tag is not self-explantory (which would be much better than a lot of text in the wiki). But "markings" remains somehow misleading, because lane information can also be placed on signposts, which is not intuitively a 'lane_marking'. But I have no other constructive proposal at the moment, except the comments below. --Martinq 09:51, 16 February 2012 (UTC)
Thanks for the hint: added a clarifying sentence in the proposal. --Imagic 12:03, 16 February 2012 (UTC)
When you have concerns about the name, it is a good idea to look at the intention of your tag:
  • Information about the continuation of the lane (:lanes) or road (if used without :lanes): left, right, through, merge_left, merge_right. For me it is the tag version of the connectivity relation, why not connectivity?
Because the information the tags provide is not a complete connectivity information. You only know that this is a left-turn lane, but you have no clue, at which lane you will end. --Imagic 08:55, 16 February 2012 (UTC)
Yes. It is incomplete, because we just define the target road, but not the target lane. But for obvious cases (which is your own argument!) the target lane can easily be deduced (for example if there is only one lane or any lane after the turn is possible). Thus I somehow still interpret it as tag version of a connectivity, but of course not as full-featured and expressive as the more complex relation.--Martinq 09:51, 16 February 2012 (UTC)
You're right: it is somehow a "light-weight" version of the connectivity relation. But I still think, that both serve their purpose: the tag version for the common situations and the relation version for the complex situations. --Imagic 12:03, 16 February 2012 (UTC)
Neither turn=left nor connectivity=left are fully intuitive, but I must admit that 'connectivity' seems to be worse than 'turn' (beside some beautity in the internal consistency which is irrelevant for the mappers). Unless somebody comes up with further arguments, I withdraw my connectivity proposal. Let's see if somebody can find something more 'self-explanatory' than 'turn' or (the somehow misleading) 'lane_marking'.--Martinq 13:09, 16 February 2012 (UTC)
Alternative: continuation?? I'm no native speaker...
  • Information about the (signposted) destination of the lane: destination=*, destination:lanes=Mordor;A666|Shire;Buckland, according to the existing tag preferrable for main roads
  • Information about the road surface turn marking only (including none) -- would require a new tag, but I'm not sure there is a data consumer for this
--Martinq 21:07, 15 February 2012 (UTC)
We already need a new key. The turn=* is only a draft and according to taginfo it is not used. So right now the only question is if turn is a good name for lane markings. Because we only specify here markings for turning and merging and nothing else, maybe turn_markings would be better? Although, turn is much shorter.... --Imagic 08:55, 16 February 2012 (UTC)
Another thought: We may have just to accept that merging lanes and turn lanes are different things and therefore should have different tags? I have no example in my mind, where turn lanes and merging lanes occur at the same time in a road section (at least such a case is extremely rare). Merging is typically more a 'after the crossing' thing while turn lanes are more a 'before the junction' thing. Thus I don't see that tagging gets more complicated (=requiring more tags at the same time) if we have a lane_merge=[left|right] tag and a turn=[sharp_left|left...] tag. I expect that in most cases only either the lane_merge or the turn/connectivity is required. Another advantage is that such a new lane_merge tag typically does not require the :lanes extension, because a left merge with the left lane typically happens on the right-most lane (=the default, the obvious) and vice versa. The new extension will cover the remaining 'special' cases, for example lane_merge:lanes=|left|. Any comments?--Martinq 09:51, 16 February 2012 (UTC)
Update: lane_merge=left is potentially ambigious (does the left-most lane merge or the right-most lane to the left?), thus something like lane_merge=[to_left|to_right] might be better.--Martinq 10:51, 16 February 2012 (UTC)
I wouldn't want to go that way! You would need an additional tag in case that turn and merge lanes are both present and those situations do exist: look at my first example for additional features. --Imagic 12:03, 16 February 2012 (UTC)
OK, you have an example - sadly one we use for explaining the proposal. I still think the occurrence of turn lanes and merge lanes at the same time is a rather infrequent constellation. I have checked several merge lanes in my area and haven't found a single example, thus my personal conclusion (no world wide statistics!) is that merge and turn lanes do not often occur at the same time (but I have a regional bias and cannot speak for the world). For our discussion: There is no right or wrong here, finally it is a subjective decision: Do we want one tag less for a few cases (unclear how many we have - 1%? 10%?) or do we want less-overloaded and (therefore hopefully) more self-explanatory tags and accept that some infrequent cases need an additional tags? My personal 'feeling' is that turn lanes and merging lanes are different things with different consequences for data consumers. They seem also to just occur coincidentally at the same place. Thus I am still in favour of using separate tags. Additionally I think there is also an adding value of establishing a separate lane_merge because this tag has a useful standalone meaning independent of this proposal.--Martinq 12:50, 16 February 2012 (UTC)
Any additional comments on this? Should we split the key turn into the two keys turn and lane_merge? (Other/better names for the keys?) --Imagic 12:24, 20 February 2012 (UTC)
Every discussed alternative to 'turn' (two keys or 'lane_marking') has also some disadvantages. I believe that the first idea with lane (including merge_to values) was a rather intuitive approach, thus let's keep it as it is. I have marked the discussion as resolved. If somebody comes up with new ideas, please feel free to re-open the discussion. --Martinq 08:32, 21 February 2012 (UTC)

I can't think of any other markings, that might be important to map. The only other markings that come to my mind are representations of traffic signs (speed limits, Stop-sign) and those are all mapped with other tags. As has already been mentioned, for routing it is not important if the turning lanes are defined by markings or by a traffic sign. In my opinion, a key marking is a seperate proposal, useful mainly for micro-mapping, just like the attempt to map/tag all traffic signs (which will not change the use of maxspeed, parking etc. So I think it is okay to stay with turn. -- A uller 13:00, 16 February 2012 (UTC)

Sharp left, left, slight left

Resolved: Added grades to the values. Complex situations are covered by the connectivity relation.

You have requested comments in your proposal: I believe we need different "grades" of left/right, because we have to deal with more than 3 directions in reality, see following example: left and sharp left turn -> the leftmost lane when coming from north allows left and sharp left. But how should that be tagged without different grades of left (or right)? I think this example should be tagged with turn:lanes=left|left;sharp_left. Other turn examples are here with slight left+left and here with right+sharp right.

Pragmatically we should define/allow 7 connectivities: sharp_left, left, slight_left, through, slight_right, right, sharp_right. Because I believe there is no junction with more than 7 outgoing directions at once, this should be sufficient for almost any junction in the world. I prefer the more natural sharp_left instead of the "technical" left_sharp. As long as we have a fixed number of allowed values, it makes no big difference for a parser if 3 or 7 values must be checked.--Martinq 21:22, 15 February 2012 (UTC)

I agree with you, that we should cover this. I will add those values and we will see if there are reasons against it. --Imagic 08:28, 16 February 2012 (UTC)
A router needs the way ids and the lanes. It's impossible for a software to know what slight_left means. If it's an additional information for humans - why not. But people will expect the router knows how to deal with that - but they can't. --Robotnic 19:17, 14 March 2012 (UTC)
Software can compare the angles of all available "left" turning outbound ways, and derive which one of the {sharp, left, slight} refers to which way. In this context "slight" and "sharp" only make sense when compared to something. Alv 19:24, 14 March 2012 (UTC)
This is correct. And for situations where this is not possible we will introduce a solution in the next step, most probably the connectivity relation or something similar. --Imagic 19:45, 14 March 2012 (UTC)
I also agree. Moved follow comment from the voting section, didn't saw that discussion was restarted here:
For routing software - and the determination of the target road - it makes no difference whether the mapper decides "sharp_left|left" or "left|slight_left" or "sharp_left|slight_left" for a 60° and 30° turn. It is always clear that the first one is "more left" (software can determine angles) and therefore means the 60° road. The turn values can be ordered and the ways can be ordered by angle -- and then matched. Thus a subjective mapper decision when using slight/sharp is no problem.--Martinq 22:28, 14 March 2012 (UTC)
Bring a formula, example code, mathematical description. Maybe it works, but it is not specified as it should be. I think every router will bring a different result and debugging will be an nightmare.--Robotnic 21:08, 15 March 2012 (UTC)
This is a proposal for a tagging scheme - not a programming tutorial. The implementation is straight-forward as Martinq already explained. If you have a junction with three ways going right and lanes leading to this junction tagged with sharp_right, right and slight_right it unambiguous which lanes leads where. For more complex situations - e.g two lanes both marked only with right and two ways going to right - the connectivity relation is proposed. So for simple situations you could rely on tags, for more complex you can use the relation. In the most common situations tags are sufficient and we can do without the relation, which is a big advantage of this proposal. --Imagic 09:45, 16 March 2012 (UTC)

Traffic lanes shared with tram and/or for parking

Foreword: I have assumed that the scope of the proposed extension is limited to lanes as part of the carriageway with lanes on which a vehicle is not restricted by any physical barriers or separation to move laterally, see wikipedia:Carriageway). This means footways/sidewalks, separate cycleways, separated (embankment) tram tracks or non-contiguous parking lots (no traffic possible even if all are empty) are not in the scope, :lanes is not intended for such 'non-lanes'. So far, so good.

Correct. I think that there is a general understanding, that separated roads should be tagged as separated ways. --Imagic 10:05, 19 February 2012 (UTC)


But we have following cases, that are related to lanes and I want to discuss the situation for them:

  • Tram tracks - if lane is shared with a tram (and not separated from the remaining traffic)
  • Parking lanes - if the lane is used for traffic (e.g. during rush hour) and for parking at different times/days

Is the proposal flexible enough to express these cases (in a future extension)? Or have we reached the limit with these cases?

My thoughts so far: railway:lanes:forward=|tram theoretically works (following the logics of this proposal), but I won't count on a broad acceptance (especially if the railway are mapped as separate OSM way). Any other nice ideas, or do you agree we should exclude tram topics completely?

I would neither ex- nor include them. As you wrote: it would work theoretically and I think also practically. If (some, most or all) mappers prefer to create a separate way for the tram track it would be also ok. You CAN use the :lanes extension to tag the tram track on the same osm-way as the road. But you are not forced to do it that way (which also would break compatibility). I think it gives us a little bit more freedom. --Imagic 10:05, 19 February 2012 (UTC)
The main issue is the 'renderer lock-in': Because the railway:lanes wouldn't be rendered, acceptance will be low (from experience). When the acceptance is low, the renderer don't include it...
So true. But if we consider this, we should never change/add anything! Because at the beginning it is not rendered! So our best guess is to simply ignore this sad fact: ignorance is sometimes a bliss.
But one more thought: rendereres or any other applications are either :lanes-aware or not. And if they are :lanes-aware they should be able to process any osm-key with :lanes and so (hopefully) a renderer which is able to draw lanes on motorways should also be able to draw tram tacks included within :lanes. To put it the other way around: this extension is completely universal. As soon as a :lanes is present, any application can/should treat a single osm-way just as if there were multiple osm-ways parallel - no matter what tags they use. And if this is implemented in some generic way we could get support pretty fast. This - of course - is some wild understatement of the implementation effort, but think of it! --Imagic 14:03, 19 February 2012 (UTC)
I have added an example to discuss the role/power of the :lanes extension for tram lines, see below.--Martinq 11:52, 19 February 2012 (UTC)

For the parking and traffic lane I have done following investigation: Using opening_hours:lanes is not fully correct, because as long as noone parks the lane is open for traffic. Now, parking:lane:both=* is already capable to capture non-parking (eg during rush hour), but it is not clear if it applies to a separate, dedicated (and interrupted) parking lane (not included in the lanes count, not suitable for traffic if empty) or a shared traffic lane (used by traffic if empty). A new tag like parking:lane:right=traffic_lane could give the information, does somebody see an option to solve it/describe it with the help of this nice :lanes proposal?--Martinq 19:18, 18 February 2012 (UTC)

That's tricky. In my region I don't know such parking lanes. There is the rule, that one is allowed to use the first lane for parking if there is enough space left for the traffic, but those lanes are not in any way marked differently. Are those parking lanes really marked as such?
No special marking, just time restricted no-parking signs: Example: When you come at day time, you see a three lane road with three equally looking lanes, but parking is explicitely not allowed by signs (otherwise one lane could be legally used for parking - as you said). At night you are allowed to lagally park (signs just disallow parking during the day) and a visitor would see two lanes for traffic and one of the lanes is occupied by parking cars.--Martinq 11:52, 19 February 2012 (UTC)
But then those are not parking lanes IMO and should not be tagged as such. Am I wrong? --Imagic 14:03, 19 February 2012 (UTC)
At least it is no dedicated parking lane. The parking:lane:both=* does not require a dedicated lane. After reading parking:lane:... carefully I conclude it defines a property of the road (parking allowed, how and when), but not defining if parking is on a dedicated parking "lane" (always the same number of lanes available for the traffic) or if a traffic lane is consumed by parked cars (one lane less available for traffic outside no-parking period). It seems to be a weakness of the parking lane tag. It can be solved with an addition to the parking-tag, for example adding the value parking:lane:right=lane for parking on a traffic lane vs. parking:lane:right=parallel for parking on a dedicated parking space beside the road. Or the :lanes extension in combination with some clever tag allows us to figure out whether or not the traffic in motion has one lane more or less during no-parking/parking periods.--Martinq 15:02, 19 February 2012 (UTC)
As I was active in the parking:lane discussion, I can confirm that it doesn't require a dedicated space - but at least parking:lane:right:parallel=lay_by/on_kerb/painted_area_only state that the parking is not on the driving lane; when said tag's value is "on_street", it's unknown - not all "dedicated space" parallel parking opportunities are "lay_by", afaik. At Proposed_features/parking:lane/Examples I've tried to show with some example photos how it affects the traffic flow, and proposed parking:lane:*:placement=inlane/dedicated. So far those tags have only 430 uses, but I could probably enter them for many sections from memory. Alv 10:57, 20 February 2012 (UTC)
Do you see any conflicts between the proposals? In my opinion parking lanes should not be covered by :lanes and in fact are covered quite well by the parking:lane proposal, as long as the parking lane does not consume a traffic lane at some point. If it does, we would need some "fusion" of both proposals, otherwise we would lose that information. Would something like parking:lane:lanes=*|*|parallel make sense (despite its inherent ugliness)? --Imagic 12:03, 20 February 2012 (UTC)


Let's have a look at the parking key: it uses the three extensions :left, :right and :both. Those extensions tell us where the lane is. This is exactly the same information we get from the :lanes extension. So I think the it should be something like parking:lane:lanes=*|*|* and parking:condition:lanes=*|*|*. (P.S: Yes, the first one is really ugly) --Imagic 10:05, 19 February 2012 (UTC)
Good thought, I like the idea. But this would require a slight modification of the current description, because no stand-alone parking:lane key (formally extended by lanes) exists. :left, :right or :both must be used. But that is not relevant for the proposal as such, but another example for its potential power and flexibility. --Martinq 11:52, 19 February 2012 (UTC)
The more I think about this, the more obvious it becomes to me, that the :lanes extension is at the right place. A few would rather like to see it as a prefix, but look at all the existing tags. Extensions like :forward, :backward, :left, :right, :both are all added as suffix. And they all give us location information. So does the :lanes extension. Why should it be at another place than all the existing extensions? I think it is a good time to close the discussion ":lanes - suffix or prefix". --Imagic 14:03, 19 February 2012 (UTC)
We have several places where one lane is effectively filled with parked cars in the evening/night, but in the daytime (often Mo-Fr only) it's no_stopping or no_parking - and could be a bus lane for some part of that time. There's some examples in Talk:Proposed_features/parking:lane#Different_intervals_for_no_stopping_and_no_parking. The second example there even has tram tracks on the left/inner lane.
And IMO eventually the tram tracks will be drawn as separate ways in their "exact" location, but that doesn't make tagging the lanes invaluable - when changing lane into a lane shared with trams it's good to know that, and it's pretty hard to infer from the geometry exactly which lane is or isn't shared. Many don't come to mind, but there's one high traffic location where left turning vehicles must change lane left onto the tram tracks some 100 m before the intersection - before that the tracks are separated by a platform and for some length by a solid line - could be a tiny curbstone, too. Alv 12:48, 19 February 2012 (UTC)
As soon as the tram track is also used as a turning lane, it is obvious that one can't tag this with two separate ways. So we have to make sure, that tram tracks (and similar "ways") can be tagged by this scheme. Right now I don't see any unsolvable problem.
I will take a deeper look at the parking proposal, as soon as I have a little more time. Right now, I'm not sure if :left/:right is a good idea, but I'll comment there ;-) --Imagic 14:03, 19 February 2012 (UTC)

Example for shared traffic/tram lanes

Highway Tram01.jpg (from Tagging samples/urban)

My tagging when having only one way for tram and road, OSM way direction assumed from front to back:

Lanes extension related: 

turn:lanes:backward=left|     - or left|through? through is not marked here
railway:lanes:backward=tram|  - or tram|none for better readability
railway:forward=tram          - or is railway:lanes:forward=tram preferrable even for a single lane?
Ok - now I have a problem. What you are telling here is wrong, because you state, that there are two tram tracks, while in fact there is only one. If we only specify on track we have another problem, because the tram track can be used in both directions and the turning lane ON THE SAME LANE only in one direction. How can we handle/tag this? I need to think about this.... --Imagic 14:03, 19 February 2012 (UTC)
  • I see two tracks (4 rails). railway=tram and tracks=2 must be tagged if mappers use only one OSM way.
Found my problem! As soon as I open my eyes I also see two tracks. Amazing! ;-) --Imagic 09:52, 20 February 2012 (UTC)
  • The 'oneway' issue for railways is a known issue and disputed, see also railway=tram. It is not the task of this proposal to solve direction tagging of tracks. I am satisfied with the fact that the position of tram tracks within the road can be handled by the :lanes extension.--Martinq 14:31, 19 February 2012 (UTC)
One quick thought: assuming we also approve the extension to the direction key (which right now I will not include in voting) and thinking of the restriction relation, I would suggest something like direction:tram:lanes=*|*|*. To be more precise: direction refers to all traffic and direction:XXX only to XXX, e.g. tram, bus, bicycle, etc. Comments? --Imagic 09:52, 20 February 2012 (UTC)
I recognized that the already existing oneway=* provides similar information. The current key even includes a similar 'traffic' specific extension like oneway:tram.--Martinq 10:23, 20 February 2012 (UTC)
Yes, you are right. But have a look at the example I just added. Do you want to tag this with the oneway key? Would this really be readable? --Imagic 10:36, 20 February 2012 (UTC)
Yes. I fully agree. Nerd alert in the current oneway key. I scratched my head when I read oneway=-1. But it is a problem of the oneway key.
While I really like to see the potential power of the :lanes extension confirmed by our discussion of this tram example here, I am not sure it is a clever decision to include it in the main proposal - at least not as one of the first examples. We need simple examples to demonstrate how simple the idea is (to avoid too complex/too complicated votes) and - maybe even on a separate page - 'advanced' examples with bicycle lanes, parking lanes, reversibles, trams, etc. to avoid does not include XXX/cannot handle XXX votes. We should avoid anything that encourage people to put the proposal too quickly into the compicated box and stop further thinking about it. My personal experience with this proposal is: The longer you think about it, the better it gets. --Martinq 11:08, 20 February 2012 (UTC)
I'm quite sure the direction/oneway/whatever will not be voted on. I will rework the proposal before the voting and clearly separate/remove/strike through parts, which are not voted on. I'm still not sure what the best way is there: move the parts to a different page, strike them through or leave them on the page and just put them in their own section. I think I'll go with the separate page... maybe. As none of the latest comments lead to any change in the proposal, I'm already thinking of voting; maybe in one or two weeks. --Imagic 11:40, 20 February 2012 (UTC)


Other tags: 

parking:lane:right=parallel   - special parking lane, cannot be used by traffic even if empty -> not included in :lanes
parking:condition...=...
sidewalk=both  
maxspeed=...
name=...
...

Optional: 

lanes=3
lanes:backward=2

--Martinq 11:52, 19 February 2012 (UTC)

New direction key vs. existing oneway key

Resolved: We keep the direction key with the forward/backward values in the examples, because the examples are more intuitive compared to the oneway key.--Martinq 09:58, 28 February 2012 (UTC)

After looking at the existing oneway=* I conclude that a new direction key is not needed:

  • oneway=no <--> direction=bothways
  • oneway=yes <--> direction=forward
  • oneway=-1 <--> direction=backward (I don't think that -1 is really well-known and widely used - and IMO very ugly)
  • oneway=reversible <--> Intended to be handled by reversible, but no full equivalence with new key
  • oneway:moped=... (in the wiki) <--> direction:moped=... (of course also for tram or bus, etc.

No question, some of the oneway values are hard to read and understand (not very intuitive), but described. Thus I don't see the urgent need to replace it by a new key providing similar information. I added a vote to exclude the direction key from the proposal.--Martinq 10:37, 20 February 2012 (UTC)

The more I think about it, the more I do not like the usage of oneway in this scenario. I don't think that many mappers would think of a lane on a highway as oneway, even if they are in fact oneways. I also do not want to include the direction key in the voting, but I want to have a solution for this ready in my pocket. Especially as I don't really like the solution with opening_hours for the reversibles. I just proposed an introduction of generic conditions for keys and together with the direction key the solution would look like this:
 lanes=3
 direction:lanes=backward|forward|forward
 direction:conditional:lanes=|backward|
 conditional=time(10:00-18:00)
Like it? Hate it?
Of course one could also write this with oneway, then it would look like this:
 lanes=3
 oneway:lanes=reverse|yes|yes
 oneway:conditional:lanes=|reverse|
 conditional=time(10:00-18:00)
Yes, it works. But which one of both is more understandable? (P.S. I refuse to use oneway=-1!) --Imagic 08:45, 23 February 2012 (UTC)
oneway=-1 is used 50.000 times (taginfo). Not much, but also not neglectable.
Is direction:lanes=backward|forward|forward more understandable? Yes! But the tag does not exist yet. oneway:lanes=-1|yes|yes gives exactly the same information. Is it ugly? Yes. Is it somehow confusing because 'oneway' is used in the context of a non-oneway road? Yes. But the tag exists and can be immediately used.
I don't comment the conditionals. This is a topic on its own - with dedicated proposals that can be discussed on these pages.--Martinq 22:31, 27 February 2012 (UTC)
Sorry, my fault. I never meant, that oneway=-1 shouldn't be used. I meant, if we agree on using oneway instead of direction I myself will most certainly not use a imo completely non-self-explanatory tag like oneway=-1. The example with the conditional I used simply because I had it in mind at that moment.
The direction=* key is already existing and even used together with forward and backward according to taginfo. So why not use it? --Imagic 09:11, 28 February 2012 (UTC)
Both, direction and oneway, are just examples to illustrate the usage (and power) of the proposal. The objective of examples is to make the proposal itself understandable. Because there was never any disagreement that 'direction=backward' is more understandable than 'oneway=-1', it makes sense to use the intuitive (but rather new) 'direction' for the examples -- simply because we want to make them as understandable as possible.
Minor: It would be better to add at least a note in your proposal that 'oneway' can be used in lieu of 'direction'. I do not insist on such a note. Thus I have marked this thread as resolved.--Martinq 09:58, 28 February 2012 (UTC)
I added a note in the proposal about the equivalence of the keys. Thanks for bringing up this issue. --Imagic 10:30, 28 February 2012 (UTC)

Naming of lanes

You propose to name the lanes of a way named with name=way1 as 

name:lanes=way1lane1|way1lane2|way1lane3

and I understand it that the name tag is the one used on the street (please correct me if I'm wrong here). Let's assume a street with a long name like Wandsworth Bridge Road or Gerhart-Hauptmann-Straße. So if we use the name tag of the street, that would make naming of the lanes quite ugly: 

name:lanes=Gerhart-Hauptmann-Straßelane1|Gerhart-Hauptmann-Straßelane2|Gerhart-Hauptmann-Straßelane3

and that's only for 3-lane-roads. Maybe name:lanes should be independant from name so one could use abbreviations i.e. 

name:lanes=GHS1|GHS2|GHS3

since those names are only used within the connectivity relation. --Seoman 13:53, 21 February 2012 (UTC)

No, I don't see a rule that the street name must be included in lane names. But after reading the proposal I understand your confusion! It needs some rework, way1lane1 in the example is very misleading.
What I understood: If lanes have no names in reality (which is common(!), only sometimes you find something like 'M25' on a lane, which could be interpreted - with some imagination - as 'lane name') the proposal recommends to define and use 'internal' lane names (not intended to get rendered). These internal lane names don't have to follow rules and therefore do not include a mandatory street name (I would guess something like 'bicycle-left' or 'bus-lane' would fulfil the need). As far as I see these 'internal' names are just to avoid the lane numbers in the relation. The reason behind this recommendation is that the lane counting (lanes tag - if used!) and number of lanes in the extension may differ. After thinking about it, I don't support this recommendation that requires inventing artificial lane names (a very 'technical' approach).
The name:lanes should also not be misinterpreted as destination(s) sometimes signposted above the lanes. For (signposted) destinations extending the existing destination=* to destination:lanes=Mordor|Shire;Buckland seems to be more appropriate.
Note: While I answered your comment you have revised it (and made it clearer). Thus my answer no longer fully matches your comment. --Martinq 14:23, 21 February 2012 (UTC)
The intention of names for lanes was simply to make the connectivity relation more readable. After reading this comments I guess, that the name key is the wrong key for this. I still would at least give the possibility to somehow name a lane and use this in the connectivity relation. Any suggestions for a better key? The comment from Martinq regarding the destination is completely correct. --Imagic 14:32, 21 February 2012 (UTC)
What do you think about a key named lane_ref, which can be used for this purpose? I would not include that in the voting, just mention the possibility to support something for the connectivity relation. --Imagic 07:59, 22 February 2012 (UTC)
I'd like to point out the key description=*, which might be suitable for this. -- A uller 08:04, 22 February 2012 (UTC)
Taken from description=*: "The description tag is for adding text that might be viewable to the end user." I intended the names of the lanes only to make the connectivity relation more readable; the names shouldn't be viewable anywhere. So I don't think this would suit well. --Imagic 08:17, 22 February 2012 (UTC)
lane_ref is better than name. However, giving lanes 'internal names' - just to avoid numbers - is a very 'technical' approach. In my opinion numbers will work better. Average mappers will not be confused by the (minor) 'lanes issue' as much as a by the recommended 'lane_ref'. lane_ref just makes the proposal look more complicated.
I suggest deleting the recommendation to use lane names (cite: 'Note: due to issues with the lanes=* key, I recommend using names for lanes.').--Martinq 21:17, 25 February 2012 (UTC)
I never really liked the name:lanes and the lane_ref would need a new key. So I guess, that it would be better to leave this out from the voting, especially because it could be easily introduced later on. --Imagic 14:02, 26 February 2012 (UTC)

Alternative to applies_to

I suggest using the key connectivity instead. Than the last example in the connectivity section would become 

type=connectivity
connectivity=bus
from=4
to=1

This is consistent with the use of e.g. service as key and value as in highway=service with service=parking_aisle. --Seoman 14:05, 21 February 2012 (UTC)

The applies_to key is optional in the connectivity relation. I am not sure if this would be a good idea, especially as it does not describe what kind of connectivity it is (always lane connectivity), instead it tells you for what kind of traffic this connectivity is valid. --Imagic 14:36, 21 February 2012 (UTC)
I agree with Imagic. 'applies_to' might not be the best solution, but 'connectitity' is worse. When following the OSM principle the given example would express a 'bus lane connectivity', but the relation does not necessarily connect 'bus lanes', just a lane connection that can be used by a bus. --Martinq 20:54, 25 February 2012 (UTC)

turn key and signposted lane information

Resolved

The current proposal states (for the turn key): The key should be used, whenever lane markings dedicate a lane to be a turning or merging lane.

This leaves some room for interpretation. Especially, signposted information like:

US "lane ends" sign US "lane reduction ahead sign" sign AT "Lane preselection" sign DE "lane reduction" sign DE "prepare to clear shoulder used as lane" sign SE "Lane preselection" sign


...might not be interpreted as "marking". But in my understanding such lanes should also be tagged with the 'turn' key (even if there is no road marking).

An attempt to phrase it more precisely:

The key is used on the way segment from the first indication via road markings or signposts to the junction or completion of merge. Lanes without markings and signposts should not be tagged by a turn value. --Martinq 12:42, 26 February 2012 (UTC)

Damned - you're getting really picky! ;-) Added the clarification - thanks a lot. --Imagic 13:28, 26 February 2012 (UTC)

Connectivity & obvious connections - discussion

Split way

The current rule set for 'obvious connections' has a weakness for connections between split ways (two way segments with a joined node).

Before junctions typically unmarked lanes then turn into 'turn lanes', thus the way gets split there. At this split we have an issue. For example the way may have lanes=2 (turn:lanes=| is omitted) before, afterwards turn:lanes=left|through|through;right. The rules don't work here, but it still somehow obvious that through lanes are connected preferrably (but not as a generic rule). Example here: [From the right to the left 2 unmarked lanes turn into 3 turn/through lanes]

Another gap: While it pretty obvious that a through lane can only be added to the right if the other lanes are left-turn (example [Heading north 2 turn-left lanes are extended by a third through lane]), the rules don't cover this.

The split of left;through to a left and through lane - or a right;through to a right and through lane - is also not covered, see [[4]]. For me as a human 'obvious' that the middle combined lane split into a separate lane, but according to the rules not covered yet.

Bicycle lanes 'crash' the rules, for example here: [Right lane added to three through traffic lanes, but right-most lane is still the bicycle lane] - even though for humans it is easy to deduce the most probable lane connections.

I tried to improve the existing rules this evening, I sadly failed. I can't offer a better - but still simple (!) - rule set. --Martinq 20:05, 26 February 2012 (UTC)

Connections across junctions

The rules also don't work for connections across junctions, for example which lanes do I end up if there are two turn-left lanes and the target way has three lanes? Be careful: At least for Germany I know that it is legally undefined which lane you must use if there are NO lane markings across the junctions.

--Martinq 20:05, 26 February 2012 (UTC)

Road merge

With the term road merge I mean situations where (at least) two ways join in the same direction: When a road with 2 lanes merges from the left and another road with 1 lane merges from the right - and the way continues with 3 lanes, forme the lane connection seems to be obvious (example [here]. The current acceleration lane rule is a special case of this generic situation, where one of the three lanes immediately gets a 'merge lane'. But I failed to find the right wording for a rule also explaining 'road merge'. --Martinq 20:05, 26 February 2012 (UTC)


Maybe we should face he fact, that those (for humans) obvious connections are extremely hard to specify as exact rules? Maybe it would be wiser, to simply state, that connections that are obvious for humans (yes, I know: very subjective) should not be tagged and let those rule set grow along the way? --Imagic 11:17, 27 February 2012 (UTC)

Voting

Discussions during the voting should be done below this. The discussion above this is based on the original, complete proposal, which can be found here. The proposal was cut down before the voting and therefore many issues above may not be relevant for the voting.

Hook turns -- turn key

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)

Concurrent voting

Resolved: Voting on Proposed_features/Lane_group was cancelled.--Martinq 17:19, 13 March 2012 (UTC)

Unfortunately we have ended up with two rather similar proposals trying to solve a similar problem -- drafted in parallel and also open for voting in parallel:

I am not a happy with this development and have started a discussion thread Talk:Proposed_features/Lane_group#Concurrent_voting with the suggestion to interrupt voting and join the efforts/proposals first and have a common discussion rather than isolated ones.--Martinq 11:03, 6 March 2012 (UTC)

Turning restrictions on junctions

In cities there are sometimes turning restrictions on junctions. For example, although there is a physical possibility to turn left on a junction, turning left is prohibited because it would cause traffic jams. Moreover, this restriction applies only to one of the roads - the below image illustrates the situation (and a real-world example on a satelite image).

Junction-no turn left.png

Forgot to sign: Tomek-k 20:34, 20. Mär. 2012

  • This proposal allows to express the road markings of lanes. For the given example, when heading north: turn:lanes=through|through;right.
  • The sign expresses the connectivity of roads, in your example that it is not allowed to turn to the left road when coming from the bottom. For mapping this information we already have a feature: Relation:restriction. But this feature does not tell us anything about lanes.
Of course the information described by both features is not completely independent, because sign and road markings can express the same: At least in countries that have implemented the Vienna Convention on Road Signs and Signals, the arrows marked on a lane are binding. This means for the given example: If the turn restriction sign is omitted, it is still not legally allowed to turn left due to the lane markings. Vice versa if there is a sign but no "through arrow" marked on the left lane it is still prohibited to turn left.
Despite this implicit turn restrictions expressed by turn:lanes (in some countries): This proposal does not deprecate Relation:restriction. It shall still be used to express the connectivity of roads/highways -- especially if there are road signs restricting directions of travel (non-lane specific information!). I think it is still a good idea to map turn:lanes=through|through;right and the turn restriction relation. This will ensure better backward compatibility for router software (and for non-lane aware applications) and additionally the legal meaning of lane markings might depend on the country.--Martinq 22:46, 20 March 2012 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Lanes_General_Extension&oldid=2515262"