On of my professor at university quite often told us that “Marketing is bullshit”. He reasoned that marketing never tells you the whole truth. I guess everyone who ever watched an ad or read some marketing brochure tends to agree with him - except marketeers, of course.

Voting in OSM

What does this have to do with voting in OSM? The result of a vote has the same problem as marketing: it never tells you the whole truth. Ten, maybe twenty, sometimes even thirty hardcore mailing list and wiki writers gave their vote and decided for the rest of humanity, what to do and what not to do. But are those who voted really the ones who actually improve our data?

What if Joe Mapper thinks, that the approved tag does not fit his needs and he uses a different tag? We have an approved proposal, so we can replace his tag with the approved one - right? What if Joe Mapper proposed something and it was rejected, but he still uses the proposed tags? They were rejected so lets delete them - right?

No.

Our core values

The foundation of OSM is that everyone can use every tags they like. No approval needed. Just don’t provide incorrect data or destroy others work. Lets have a look at the core values of OSM: Do-ocracy, Actions speak louder than words, without need for central sanction or even post-hoc approval.

I guess, that’s pretty clear. If no one needs an approval, why do we … sorry, I meant… why does a very limited number of people vote? If an approval is not necessary, why does something have to be approved?

Isn’t voting itself against our core values?

Data consumers

It seems obvious to me why proposal-writing and voting-ecstasy got a little out of control: data consumers.

All our data is completely worthless without someone processing it: drawing some nice maps, leading us our way and much more. And data consumers need clear definition: this tag means this and that tag means that. So they want approval: this tag is “good” (as in “approved”) and this is “bad” (as in “not approved” or even worse: “rejected”). If everything is clearly defined, it is easier to process our data. But there is one thing, that is quite often forgotten:

You can not process voting results.

Clarification added at 21:00 CET 04.01.2015: In my opinion the pressure comes from the data consumers, but not only directly. Sometimes mappers want something supported in their favorite application and they think that all they need is some “official” and “approved” tag. Gladly this is not true.

Back to do-ocracy

Clear definitions about how our data can be interpreted are in the interest of all. But those definitions should not be approved, they should evolve. If we approved a tagging scheme and no one uses it, it is useless. If it is used, but completely inconsistent, because it is too complex, it is useless.

We should not vote on new tagging schemes, we should support them - or not.

Lets replace voting in our proposals by usage numbers like taginfo and a list of supporters (mappers and consumers). No rejecters. If you don’t like the proposal write your own, convince others to use it and try to get some support from data consumers. Adapt it from time to time, if necessary. And after a while look at the usage numbers and the number of supporting consumers.

Let the numbers do the voting.

P.S: No, I will not put that proposal up for a vote.

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…