Proposal:Lanes General Extension

The Feature Page for the approved proposal lanes general extension is located at Lanes

The Feature Page for the approved proposal lanes general extension is located at Key:turn

lanes general extension
Proposal status:	Approved (active)
Proposed by:	Imagic
Tagging:	[[Key:<osm key>:lanes|<osm key>:lanes]]=[[Tag:<osm key>:lanes=<value1>|<value2>|...|<value1>|<value2>|...]]
Applies to:
Definition:	Specify properties for each lane of a way
Rendered as:	Some renderers may show the lanes at very high zoom level, but the major target for this are navigation devices
Draft started:	2012-02-03
RFC start:	2012-02-06
Vote start:	2012-03-05
Vote end:	2012-03-24

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 this general extension the key turn is then used to specify turn lanes. Based on the ideas of Walter Schlögl and Zverik.

This proposal was reworked and seriously cut down before voting. The original, unchanged version of this proposal, before it was reworked for the voting can be found here. It is my intention to propose further extensions based on this general tagging scheme, among others:

• Center/median turn lanes
• Reversibles
• Lane connectivity
• Left-hand/Right-hand traffic (information needed for renderers)
• Dividers between driving directions and lanes

I decided to start only with the core (:lanes extension) and the easiest, but also most useful extension (turn key).

I will try to answer frequent questions during the voting in the FAQ.

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 information 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 on the layout of lanes
• Backward compatible as far as existing tags are not "redefined" in any way
• Completely open for extensions

Furthermore, I will introduce a new tag to support turn lanes which enables navigational devices to give more accurate and detailed navigation instructions.

Tagging

General extension :lanes

This is a scheme for recording 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 in 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 in case of lanes running in both directions; see for example the planned new key for reversible). 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.

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 a 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 a 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=none|lane|none|none|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 Common Questions section for this.

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

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

In the following image the road is divided into 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|none|none|none|none
 cycleway:lanes:backward=lane|none|none|none

• Those tags are for compatibility with existing applications. They only count the lanes for motorized traffic as described in lanes=*. See the Common Questions section for this.

• I added the none for better readability.

Common Questions

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 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, then the number mentioned in the lanes key, in case there are lanes for non-motorized traffic. But if we redefine the existing lanes key we will break compatibility with existing applications and don't gain anything in return.

Left-hand/Right-hand traffic

Without the knowledge if on a way is left-hand or right-hand traffic 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. As this information can easily be added later on, I will cover this in a future proposal

Why the vertical bar as separator?

The character which separates the values of the lanes must be 1) rarely used right now and 2) easily distinguishable. My first choice was the comma, which turned out to by a bad choice. Then in the discussion the semicolon was suggested, but this would break compatibility with existing values, which already contain the semicolon. After all, we agreed on the vertical bar, which can also be interpreted as some kind of lane divider line.

Prefix/Suffix

There are two reasons, why the :lanes extension is added at the end of the key as suffix and not at the beginnig.

• The existing suffixed :forward, :backward, :right, :left and :both are all added at the end. They all have the same purpose as the proposed :lanes extension: they tell you, that the given key/value pair is not valid for the whole osm-way, but only for a specific part. For consistency the :lanes extension is therefore added at the end of the existing keys.
• If the lanes extension would be added at the beginning, all existing editors would sort the extended keys (e.g. lanes:turn) far away from the non-extended keys (e.g. turn). Especially if default values are used, this would seriously reduce readability.

Comments

Please use the Discussion page for this.

Voting

Please vote now, using {{vote|yes}} or {{vote|no}} and sign with -- ~~~~ . Please justify your decision - no matter if positive or negative.

• I approve this proposal. -- Imagic 17:51, 24 March 2012 (UTC)
• I approve this proposal. -- Geri 19:05, 23 March 2012 (UTC) 20:04, 23 March 2012 (UTC)
• I approve this proposal. -- Ch. Schwertner 08:43, 23 March 2012 (UTC)
• I approve this proposal. --hm1 7:42, 15 March 2012 (UTC)
• I approve this proposal. --Martinq 10:39, 5 March 2012 (UTC)
• I approve this proposal. -- A uller 12:35, 5 March 2012 (UTC)
• I vote blank about this proposal. I appreciate the effort to stay backward compatible but sceptical about the complexity. --Pieren 13:39, 5 March 2012 (UTC)
• I approve this proposal. -- Soldier Boy 14:26, 5 March 2012 (UTC)
• I oppose this proposal. Every lane should be a separate way. See [1]. --Fabi2 18:21, 5 March 2012 (UTC)
• I approve this proposal. Grenzdebil 20:08, 6 March 2012 (UTC)
• I approve this proposal. Gnuzifer 22:19, 6 March 2012 (UTC)
• I oppose this proposal. There's no alternative to separate lanes. -- Errt 20:00, 7 March 2012 (UTC)
• I approve this proposal. That’s very hard for the mapper and logical faults are hard to find, but it's the best at the moment.--Hurdygurdyman 09:15, 8 March 2012 (UTC)
• I oppose this proposal. So much complex....I wouldn't never map using such scheme. -- Al3xius 08:56, 9 March 2012 (UTC)
• I oppose this proposal. Another feature for blind drivers? - useless! --R-michael 18:00, 9 March 2012 (UTC)

Beside the actual use for sighted people, do I understand you correct, that blind people are useless people? --Imagic 18:13, 9 March 2012 (UTC)

• I approve this proposal. complex topic, but good try, let us test it. (Author of lanes ex) --Bürste 11:47, 12 March 2012 (UTC)
• I approve this proposal. I haven't seen anything easier to map complex lanes and with support inside the editors this could work. --Ckruetze 12:14, 12 March 2012 (UTC)
• I approve this proposal. This is the first of many approaches that I have understood right away, so thumbs up. And I deeply hope that lane tagging will keep those micromappers from desperately drawing single lanes, which leads to complete chaos (for mappers, renderers and routers).--BorisC 21:55, 12 March 2012 (UTC)
• I approve this proposal. A good approach that hopefully stops some mappers from mapping physically inexistent features without any chance for (data-)users to fix these issues in a pre-processing step. --BearT 10:23, 14 March 2012 (UTC)
• I oppose this proposal. slight_left,sharp_left,... is not defined --Robotnic 11:22, 14 March 2012 (UTC)

Could you please explain, what is not defined? --Imagic 13:01, 14 March 2012 (UTC)

A router does not know what it is. Should it be a message for humans? Is -32 degree left or slight_left?

Right at the beginning of the proposal I write about features excluded from the voting and also provide a link to the "complete" proposal. Your question is answered there; see lane connectivity. --Imagic 19:40, 14 March 2012 (UTC)

Deleted comment, moved to discussion. --Martinq 22:18, 14 March 2012 (UTC)

• I approve this proposal. --Extremecarver 12:50, 14 March 2012 (UTC)
• I approve this proposal. Probably not perfect but certainly a step in the right direction--De muur 18:55, 14 March 2012 (UTC)
• I oppose this proposal. I like the '|' as a delimiter, but the ';' is just wrong, see comment by BorisC on 3 Feb 2012 on discussion page. Additionally, I am concerned that the lane direction issue is not touched. Marking boundaries for left-hand or right-hand traffic won't solve this, because cycle and center turn lanes can be driven in both directions, and opposite direction cycle or tram lanes may be on the right side in a left-hand driving country, and vice versa. As lane connectivity is not regarded either, there is currently no use for this tagging scheme. --Fkv 08:54, 16 March 2012 (UTC)

The ";" was part of the discussion; it is heavily used and it can not be dropped without introducing serious incompatibility. Center turn lanes and lane direction is solved using the direction=*. And here you find the Lane connectivity.

The ";" is not heavily used within this tag yet, because it's a new tagging scheme. See discussion page for what ";" normally means. You shouldn't link to direction=* because that page gives you 3 different meanings, none of which has anything to do with lanes. The approaches on the other cited pages don't look convincing but I won't discuss them here because it's not what we are voting on. --Fkv 11:43, 16 March 2012 (UTC)

• I approve this proposal. Easily understandable. --Simon04 08:58, 17 March 2012 (UTC)
• I approve this proposal. After having used the proposed tagging scheme for a variety of junctions from simple to complex, including decreasing the complexity of two "spaghetti junctions" I had created previously (before and after images taken -- might upload here later), I'm pretty comfortable with how this is working. --Ceyockey 01:51, 24 March 2012 (UTC)
• I approve this proposal. A proposal with cycleways! -- Species 09:53, 20 March 2012 (UTC)
• I approve this proposal. A well thought out proposal with reasonable complexity - it's a complex matter after all! Planned extensions look promising, too. --Seoman 11:02, 20 March 2012 (UTC).
• I approve this proposal. -- BerndSch 19:46, 23 March 2012 (UTC)
• I approve this proposal. --PanierAvide 10:02, 24 March 2012 (UTC)

Voting has ended. The proposal was approved with 22 votes in favor, 6 against and 1 blank vote.

See also

• turn=*
• 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