The history of the lanes-suffix is a history full of misunderstandings

Posted by imagic on 26 December 2014 in English (English).

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.

A suffix is a suffix is a suffix

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.

Example: While maxspeed=50 tells us that the speed limit is 50 on the whole road, maxspeed:forward=50 tells us, that this speed limit is valid for one driving direction, but not the other. It is the same when using all the other suffixes, including the :lanes suffix: while minspeed=80 tells us that the minimum speed for the whole road is 80, minspeed:lanes=100 80 tells us that the minimum speed on the leftmost lane is 100 and on the rightmost is 80.
There is no change in meaning of the key nor its values, we only change the scope. (By the way: I do not think of “100 80” as the “value”, but instead of the separate lane-dependent values “100” and “80”.)

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!

Again: the problem with counting

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.

Login to leave a comment