A long time ago (i.e. three years) no possibility existed in OSM to tag the existence of turn lanes. As more and more OSM-based navigational devices emerged, people became envious of commercial devices which often had very helpful lane assistants. So the need to provide information about turn lanes was increasing and people started to come up with some tagging schemes.
I remember at least two of them in detail:
The approach from benshu with the turnlanes:turn relation. It even came with a great JOSM plugin, but it had some serious drawbacks, which prevented its breakthrough: geometric information as tag value (the length of the lane) and - the all-time-favorite-show-stopper - a relation.
The lanes:turnXXX approach from Zverik. Just like the previous it concentrated solely on turn lanes. When put on vote, it was rejected. Maybe because it involved counting, but that’s just a wild guess on my side.
I felt that it is now my turn to come up with something. I dug through different proposals, read a lot of threads on various discussion forums and tried multiple tagging schemes in practice. The result was the proposal for the :lanes suffix, which was intended as universal approach for lane-dependent properties and was a collection of all the - in my opinion - good ideas from different people I found during my search. After some cutbacks and adjustments I put it on vote and it was accepted - hooray!
But getting a proposal approved and getting a tagging scheme to be used are two completely different things. Especially as some misunderstandings persist.
The :lanes suffix is just that: a suffix. Just like :forward or :backward, :left or :right. All those have one thing in common: they take existing keys with their defined values and only change their scope.
Most important: there is no such thing as a “maxspeed:forward” key or a “minspeed:lanes” key, there are only the keys “maxspeed” and “minspeed” with their defined values. This is also true for “turn” and “change”, even if they are almost exclusively used together with the suffix :lanes!
A golden rule in data definitions is: keep it simple, intuitive and especially avoid exceptions. A perfect example of a violation of that rule is the definition of the key “lanes”. It could have been so simple: count the number of lanes, put it into the key - done. But instead we have a nearly endless list of exceptions: only motorized traffic, only full-width, no parking lanes, no bicycle lanes, no … oh forget it! But no one really cared. Until the :lanes suffix came, which followed the golden rule. And now we have e.g. roads with four values in keys with the lanes-suffix but only lanes=3… oh wait… no, that’s another exception… lanes=2… I think. And people start asking why does the one key say three… dammit… TWO lanes and the other keys say four lanes? Simple answer: because the “lanes” key has a very bad definition.
How can we fix this? I don’t know. Change the definition of a key that is used over four million times? Not sure. Is it even necessary to fix it? Not sure either. It’s not a problem for data consumers, they can rely either on one or the other information. But how can we explain this discrepancy to Joe Mapper? I don’t know…
P.S: A few days ago someone meant, that we need some extra definition for the :lanes suffix when used together with half-width lanes. I thought about the golden rule then…
Comment from Zverik on 26 December 2014 at 18:23
Why not keep :lanes suffix consistent with lanes=* and introduce another one for all types of lanes?
Comment from tomhu on 6 January 2015 at 18:49
Clearly there is no consensus on the type of lane the lanes-key is supposed to represent. OTOH routers need that information for the type of vehicle routed. At the moment motorized traffic seems the sensible default – although I believe that is going to change dramatically.
A quick fix could be another suffix for the lanes key to identify all lanes by using existing keys as suffixes – terribly confusing.
Comment from ConsEbt on 20 March 2016 at 06:52
A bit late but here are my 2ct worth. Keeping something broken just for backwards compatibility makes no sense to me. If - by now - it makes more sense to count all lanes (motorised and non motorised) the community should do it.
It is also important to understand that while in some countries the bicycle lane might never been heard of while in others they are very popular and important aspect of the commute of many. Same applies to special bus or T2/T3 lanes…. all very country specific but the tagging should be able to handle it.