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:

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.

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:

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):

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.

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.

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)

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 ";" 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. 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).