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.

… See full entry

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.

… See full entry