Proposal:Lanes General Extension/ProposalPreVoting

This is the complete, unchanged version of the proposal, before it was reworked for the voting.

---

A simple, straightforward extension of existing tags to specify properties not only for a way as whole but for the lanes of the way instead. Based on the ideas of Walter Schlögl and Zverik.

Rationale

There is still no accepted, general way of specifying properties for the lanes of a way. This raises the problem that some feature can't be mapped at all or only by splitting ways which introduces additional problems. The need for lane properties comes mostly from routing applications, which need informations like which lane is a turn lane, on which lane a specific vehicle (hgv, bicycle, tram) is allowed to drive, and so on. But also specialized renderers could use it to show the lanes on very high zoom levels.

This proposal tries to solve these problems by an extension to already existing tags. Its main properties are:

• Every existing and future key can be used to either tag the value for the whole way or for each lane of the way
• Easy to identify: look at the street and you know the tags and vice versa
• Relations only where needed: relations are often hard to identify and understand and therefore are only used to connect the lanes from one way to another and only if the connection is not obvious.
• No need to map lanes as separate ways.
• No restriction to the layout of lanes
• Backward compatible as far as existing tags are not "redefined" in any way
• Completely open for extensions

Tagging

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. In such case, the value of that key then contains the values for each lane separated by a | (vertical bar) in left-to-right order as viewed in the respective driving direction of those lanes (resp. in the osm-way direction for the reversibles - see below). A simple example with maxspeed on a one-way street:

 lanes=3
 maxspeed:lanes=80|50|50

This would be a road with three lanes and with a maxspeed of 80 on the leftmost lane and 50 on all other lanes.

In the common case of two driving directions we need to use the already existing :forward/:backward extension.

 lanes=6
 lanes:forward=3
 hgv:lanes:forward=no|yes|yes
 hgv:lanes:backward=no|yes|yes

This is a road with three lanes in each direction and heavy good vehicles are prohibited on the leftmost lane.

This is already the main part of the proposal. Nothing fancy. Everything that follows now adds additional features like turn-lanes, reversibles, strange lanes layout, lane connectivity and so on. These are not the core of this proposal but I add them anyway to demonstrate, that a complete tagging scheme is possible with this proposal.

Additional features (optional)

In this section I will show how to solve some common problems using this tagging scheme. For some of the problems new features are necessary. They are completely independent from the :lanes extension and may or may not be in the final proposal. You may vote on the discussions page which features should be included in the final proposal. Please do so - thanks.

The new features will use the following tags:

For lanes running in both directions:

 <key>:both_ways=<value>

For all center turn lanes and passing lanes:

 reversible=[median|passing]

For turn and merge lanes:

 turn=[left|slight_left|sharp_left|through|right|slight_right|sharp_right|
       reverse|merge_to_left|merge_to_right|none]

For very complex lane layouts an extension to the direction key:

 direction=[forward|both_ways|backward|.. existing values ..]

Turn lanes

Turn lanes are one of the main reasons why openstreetmap needs lane tagging. Everyone who ever used a navigation device with lane guidance knows how convenient exact instructions can be. I suggest a new key turn for this:

   turn=[left|slight_left|sharp_left|through|right|slight_right|sharp_right|
         reverse|merge_to_left|merge_to_right|none]

Value	Description
left	left turn (only)
slight_left	slight left turn (only)
sharp_left	sharp left turn (only)
through	going straight through (only)
right	right turn (only)
slight_right	slight right turn (only)
sharp_right	sharp right turn (only)
reverse	reverse/U-turn (only)
merge_to_left	this lane merges with the lane to the left of it (only)
merge_to_right	this lane merges with the lane to the right of it (only)
none	there are no turn indications on this lane. Used especially for better readability in case of many lanes

The turn key is used on the way segment from the first indication via road markings, signposts or similar indications to the junction or completion of merge. Lanes without explicit indications should not be tagged by a turn key.

An example of a three-lane road, with one left-turn, one through, and one right-turn lane:

 lanes:forward=3
 turn:lanes:forward=left|through|right

What about if the rightmost lane is also a through lane? No problem. In openstreetmap there is already the convention to allow more than one value for a key using semicolon as separator. So let's do that:

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

As the past has shown, no proposal will ever be approved if it doesn't consider bicycle lanes, so let's make an example with one of those (on a one-way):

 turn:lanes=left|left|through|through;right|through;right
 cycleway:lanes=no|lane|no|no|lane

This is a road with five lanes, two of them for bicycles. The two leftmost lanes are for left-turn (one motorized, one for bicycles) and the two rightmost lanes are for right-turn and through (again: one motorized and one for bicycles).

You may ask: "Where's the lanes=* key in the last example?" See the problems section for this.

Note: there seems to be a (dead?) proposal for this key, which is very similar to the way presented here.

Reversibles

In some countries lanes may travel in either direction depending on some conditions (see wiki). After some thoughts this is pretty straightforward and can be done without any new keys. Here an example with a time restriction.

 lanes=3
 opening_hours:lanes:forward=24/7|18-10|no
 opening_hours:lanes:backward=no|10-18|24/7

Please note, that we do not specify lanes:forward or lanes:backward, as these has no constant value in this situation.

As opening_hours is not very intuitive in this case another way to specify time-dependent values would be preferable. Currently there is a proposal which introduces a way to do so (and others). The proposed :lanes extension could also be used on this conditional tags.

Center/median turn lanes

In some countries there exist center turn lanes, which allows traffic from both directions to pull to make a left turn. This needs another extension, because these lanes are neither forward nor backward but for both directions.

 lanes=3
 lanes:forward=1
 lanes:backward=1
 lanes:both_ways=1
 reversible:both_ways=median

For this example we need the extension :both_ways, which corresponds to lanes which allow traffic for both directions and we need the new key reversible, which specifies which kind of reversible the lane is. For the reversible key I suggest the following (see the wikipedia link above for details):

 reversible=[median|passing]

Value	Description
median	Median/center turn lane
passing	Passing lane

Difficult lane layout

The only lane layouts that will cause problems with this scheme are ones, where the directions of the lanes are not somehow separated. Let's assume a four lane road, where motorized vehicles can go forward on the leftmost two lanes and on the rightmost lane and in the middle a bicycle lane for both directions exist. My first idea was this:

 direction:lanes=forward|forward|both_ways|forward
 cycleway:lanes=no|no|lane|no

Big problem here! If the way is reversed the direction information is destroyed. So how about this:

 direction:lanes:forward=forward|forward|both_ways|forward
 cycleway:lanes:forward=no|no|lane|no

Problem solved. Not too elegant but I guess this won't be needed too often and in most cases it would be much wiser to split this way. Please note, that this introduces an extension to the direction key:

 direction=[forward|both_ways|backward|.. existing values ..]

According to taginfo the values forward and backward are already used, so actually only both_ways would be a new value.

If you are missing the lanes=* tag in the examples, see the problem sections.

This extension to the direction key might also solve the 'oneway' issue for railways. For this we need traffic-related direction, e.g.:

 direction:tram=both_ways
 direction:bus=forward
 direction:bicycle=both_ways

If we use this together with the :lanes extension we could tag the following situation (assuming osm-way from front to back):

 lanes=3   (maybe these are four lanes, but I am not sure about this)
 turn:lanes=none|left|none
 railway:lanes=|tram|tram
 direction:lanes:forward=backward|backward|forward
 direction:tram:lanes:forward=|both_ways|both_ways|

This would be the shortest way to tag this. If you only want to use the direction key for the tram traffic, you could also tag this the following way:

 lanes=3
 lanes:backward=2
 turn:lanes:backward=left|none
 railway:lanes:backward=tram|
 railway:forward=tram
 direction:tram:lanes:backward=both_ways|
 direction:tram:forward=both_ways

This is longer, but for the non-tram-lanes it is more readable, at least in my opinion.

One last note: as Martinq pointed out, the direction=* and oneway=* keys carry more or less identical information:

• oneway=no <--> direction=both_ways
• oneway=yes <--> direction=forward
• oneway=-1 <--> direction=backward
• 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.

So actually we wouldn't need any new kew or value at all if we just use oneway. At least in my opinion direction is much more intuitive in this context and therefore I will leave this issue up for discussion (and out of the voting). Thanks for pointing this out.

Lane connectivity

Lane connectivity describes the connection of the lanes from one way to the lanes of another way. This is usually needed by routing applications. As more than one way is involved this can only be solved by a relation. Note that you will only need the relation if the connectivity is not obvious! There is no need to use a relation to specify that the only existing right-turn lane connects to the only lane present in the way going right. ;-)

I suggest the following relation, whereas its members (from, to, via) are the same as for the restriction relation.

Key	Value	Description
type	connectivity	Marks that this is a connectivity relation.
from	numbers	Numbers of lanes on the from way. If more than one lane should be connected, the key would change to from:lanes and the lanes would be separated (as usually) by a vertical bar.
to	numbers	Numbers of lanes in the to way. If more than one lane in the to way is connected to a lane in the from way, than (as usually) use semicolon to separate them. In such case, the first to lane given, should be interpreted as the "straight" lane.
applies_to (optional)	kind of traffic	Which kind of traffic this connectivity applies. See the description of access for possible values. Example: applies_to=bus;bicycle. I am deliberately not using the convention of the restriction relation (like type=restriction:bus) to allow more than one kind of traffic to be specified at once. This also can be used for more than one lane group, again separated by a vertical bar.
preferred (optional)	yes or no	This should be used on Y- or T-shaped junctions, to specify that this is the "main direction" of the road. This should solve the bifurcation problem of routing applications.
except / day_on / etc. (optional)	see restriction relation

Numbers are used to specify lanes, starting from the outermost lane with number 1.

Furthermore theoretically a lane reference could be used for better readability, but 1) needs additional tagging on each way and 2) would introduce a new key, which contains some arbitrary reference, which is not represented by any existing object and therefore contradicts the usual openstreetmap policy. Nonetheless I will show some examples using this approach for demonstration purpose and would like everyone to comment on this issue here.

 lane_ref:lanes=lane1|lane2|lane3

The lane_ref will most likely not be included in the voting!

The relation specifys that the from lanes of the from way connect to the to lanes of the to way. If the connection is only valid for certain kinds of traffic, this will be given in the applies_to key. Additional restrictions are given in the same way as for the restriction relation.

If not only one group of lanes should be specified in the relation, the :lanes suffix is added and the groups are as usually separated by a vertical bar.

This relation is only used for connection of lanes, which are not obvious. So applications should first consider default lane connections (as given by traffic rules and laws) and afterwards use the information from this relation to adjust those connections.

Note: as one can specify an arbitrary number of connections within a single relation, there should be no need for more than a single relation for a pair of ways.

In the following example the outermost lane (number 1) connects to the inner lane (number 2) of the following way:

 type=connectivity
 from=1
 to=2

If you want to connect more than one lane to the lanes of the following way, use the :lanes extension:

 type=connectivity
 from:lanes=1|2
 to:lanes=2|3

In this example lane 1 of the originating way connected to lane 2 of the following way and lane 2 of the originating way connected to lane 3 of the following way.

This example demonstrates the use of a reference for each lane using the lane_ref key (on oneways). First we specify lane references for the first way

 lanes=2
 name=Hintertupfinger Oberallee
 lane_ref:lanes=way1lane2|way1lane1

And now the references for the second way:

 lanes=3
 name=Kuckuckshof
 lane_ref:lanes=way2lane3|way2lane2|way2lane1
 

Now we connect those lanes:

 type=connectivity
 from=way1lane2|way1lane1
 to:lanes=way2lane3|way2lane2

So we connect the two leftmost lanes (way1lane1 and way1lane2) of the originating way ("Hintertupfinger Oberallee" with two lanes) to the two leftmost lanes (way2lane2 and way2lane3) of the following way "Kuckuckshof". The default connection (by traffic rules) would have been to connect way1lane1 with way2lane1 and way2lane2 with way2lane2. Both were overridden by the relation and now from way1 there is no lane connection to the rightmost lane of way2 (lane2way1).

If one lane connects to more than one lane in the following way, we use semicolon to separate the lanes in that way:

 type=connectivity
 from=1|2
 to=1;2|3;4

So lane 1 connects to lane 1 and 2 of the following way and lane 1 from the originating way connects to lane 3 and 4 of the following way.

And finally an example with a lane connection only valid for buses:

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

This tells us, that lane 4 of the originating way is connected to lane 1 of the following way, but this connection is only valid for buses.

Obvious connections

To reduce the need for the connectivity relation, I guess it would be wise to define some rules, which connections are "obvious" and need not to be mapped. The rules should be very simple, intuitive and generally recognized. In my opinion the following rules should cover many case (I use way A for the originating way and way B for the following way and only consider one direction):

Situation	Rule
A and B have the same number of lanes	Every lane of A connects to the same lane of B (i.e. lane 1 connects to lane 1, 2 to 2, ...)
B has more lanes and no merge_to_left/merge_to_right lanes	Every lane already present in A connects to the same lane in B and the additional lanes of B are added on the inner side by default. If turn lane(s) not present in A appear on the outer side in B, the additional lanes are placed on the outer side instead.
B has more lanes and the outermost lane(s) is/are merge_to_leftmerge_to_right lane(s) and there are no merge lanes on A. An example for this would be acceleration lanes on motorways.	The same rule as right before, but the merge lanes are ignored.
A has a merge lane and B has one lane less	Lanes outer of the merge lane are connected 1:1 from A to B. The merge lane together with the lane it merges with connect to the next lane of B. All following lanes are connected 1:1 from A to B. (This is pretty complicated to describe, but if you think of it: how else should they connect?)
What else?

Please comment on this and/or provide additional "obvious" connections.

Turning restrictions for lanes

The current restriction relation can be extended to support turning restrictions for lanes just like any other tag/relation by adding :lanes to the restriction key.

For example if the rightmost lane is a right turn lane, but allows to go straight for buses, this could be tagged like this (I assume a way with two lanes):

 type=restriction
 restriction:lanes=|only_right_turn
 except=bus

As existing applications don't know the restriction:lanes key they will ignore this restriction (as they should).

Default values

It would be easy to specify some kind of default value for all lanes and then override the value only for specific lanes. Consider the first example:

 lanes=3
 maxspeed:lanes=80|50|50

This could also be tagged as:

 lanes=3
 maxspeed=50
 maxspeed:lanes=80||

This might be the preferred way for existing osm-keys, because it provides at least some value to applications, that are not lanes-aware.

Examples for additional features

I already gave some example throughout this proposal. In this section I want to show some example for the (optional) additional features.

Turning lanes

In the following image the road is divided in five parts:

The tags for the parts (from left to right) would be:

 lanes=3

 lanes=3

 lanes=4
 turn:lanes=left|through|through|merge_to_left
 
 lanes=3
 turn:lanes=through|through|merge_to_left

 lanes=2

Now a complex example with a british road (left-hand traffic) and some cycleways (I think so at least):

 lanes=7 *
 lanes:forward=4 *
 lanes:backward=3  * 
 turn:lanes:forward=left;through|left;through|through|right;through|right
 cycleway:lanes:forward=lane|no|no|no|no  **
 cycleway:lanes:backward=lane|no|no|no  **

* Those tags are for compatibility with existing applications. They only count the lanes for motorized traffic as described in lanes=*. See the problem section for this and discuss about this on the Discussion page.

** I added the no for better readability.

Center/median turn lanes

An example for a median turn lane (or center turn lane) on an image from wikipedia:

 lanes=3
 lanes:forward=1
 lanes:backward=1
 lanes:both_ways=1  (actually this is not necessary)
 reversible:both_ways=median

Bifurcation

Consider the following junction:

For a navigational device it would be nearly impossible to determine which of the upper two roads is "straight through" and therefore it doesn't know if it has to advise you to "keep left", "keep right" or don't give any advise at all (aka the bifurcation problem). Assuming the "left" one is to be considered "through" we could tag this with the proposed connectivity relation. We connect the rightmost lane to both lanes of the way going "right" and specify that this is not the preferred direction.

 type=connectivity
 from=1
 to=1;2
 preferred=no

Problems

The issues with the lanes tag

In some examples I did not use the lanes=* tag. The reason for this is that the current definition of the lanes=* tag has several ambiguities and shortcomings. For example the english wiki page states, that lanes only means lanes for motorized traffic. In the same sentence it links to a wikipedia article listing bicycle lanes. In the german wiki page motorized traffic is nowhere mentioned and it seems to include all kind of lanes. There was also a short discussion here.

For this reason I decided not to make any assumptions or links to this proposal. The lanes key will not be redefined in any way and should continue to be used for what it was used up to now: only for lanes with motorized traffic. This of course will lead to the situation, that the number of lanes in a :lanes extended key might be different, than the number mentioned in the lanes key. But if we redefine the existing lanes key we will break compatibility with existing applications and don't gain anything in return.

You may comment on this on here.

Left-hand/Right-hand traffic

One problem of this proposal is the missing information about left-hand/right-hand traffic. Without this knowledge the exact lane layout is unknown, because one doesn't know if :forward is left or right from :backward. Without this information routing is possible, but rendering (of the lanes) is not. One solution for this would be to tag the kind of traffic on (e.g.) the administrative borders and - if necessary for example near the borders - on the ways itself.

Merging ways by lanes-unaware editor

Editors, which are not aware of :lanes, might destroy :lanes tags when ways are merged, simply by appending the value of one way to the value of the second way, separated by a semi-colon.

Need for new keys

Everything that can be mapped now for a single way can with this scheme be mapped for a single lane. But this doesn't mean that in some circumstances tagging might not get ugly. Assume a road with three lanes and the rightmost lane is only for buses and bicycles. With the current keys this has to be mapped as:

 lanes=3
 access:lanes=||no
 bus:lanes=||yes
 cycleway:lanes=||lane

Although this is perfectly correct, that's a lot of tags! But currently it can't be tagged differently (please note: actually this is not a problem of this scheme, but more of the existing tags). If we assume a single new key that gives us the possibility to tag the vehicle restrictions with one tag instead of three it will look like this:

 lanes=3
 newkey:lanes=all|all|bus;bicycle

Again please: this is not a problem of the tagging scheme presented in this proposal.

Comments

Please use the Discussion page for this.

See also

• turn=*
• direction=*
• Experimental map showing lanes on motorways for a limited region from Soldier Boy
• Comparison of different lane tagging approaches
• Relation:restriction
• Proposed features/Lane_group
• Proposed features/Turn_Lanes
• Proposed features/turn_lanes
• Proposed features/lane directions
• Proposed features/lane:x:direction
• Proposed features/lane and lane group
• Proposed features/Lanes as Relations
• Proposed features/Lanes ex
• Proposed features/Divider
• Relations/Proposed/turn lanes
• Relations/Proposed/Lane