Browsing the German OSM forum today I noticed that the OSMAnd android routing app developers were asking the community for an opinion on which “lane” tagging proposal to implement. My first reaction was: well didn’t such a proposal pass just a while ago and why on earth don’t they know about it? But on reflecting a bit, I had to admit, that I probably really only happen to know that we have a fully functional lane tagging scheme by accident.
Our tagging proposal and voting procedure has often been belittled and is the target of many jokes. Myself being one of the larger offenders in that respect. It can be argued that for the typical “I need a value for tag X that doesn’t exist” situation it just leads to massive bike shedding instead of quick resolution. I have at times simply started documenting and using a tag completely ignoring the proposal process (see mofa).
However we have had two long ongoing disputes in areas that impact usability mainly for routing applications where a unilateral decision without community and developer buy in hasn’t worked: lane tagging and conditional restrictions.
While the effort to support the three or four different ways of tagging a cycleway in a style sheet is small, expecting all routing applications to implement the 3 or 4 different lane tagging proposal was and is just unrealistic.The usual tiebreaker that the more sucessful in day to day use proposal wins (the voting with the feet principle) doesn’t seem to work in such situations. As we all know adoption and widespread usage of a tag in OSM is mainly driven by either being able to see it directly on a map or by it having direct effect on applications. Particularly with lane tagging this has led to a classical “hen and egg” situation were lanes have not been tagged because the tagging was not being utilized at all.
We now have resolution, as far as we can ever have resolution in OSM, in two significant areas of tagging. The missing piece of the puzzle seems to be simply to make our contributors aware of the change. A long time mapper that doesn’t follow the tagging list and has never mapped lanes is not going to magically look up the lane tagging guidelines the next time he adds a street, he will just carry on with his established way of mapping.
OSM lacks a method for actively getting this kind of news out to contributors. The closest we get right now is tweeting, but that only reaches a small percentage of the community and in the past hasn’t been used for such mundane news. I’ve done some thinking about extending the OSM API to include access to the users “inbox” and some kind of system wide message system that could be used by editors to display such messages on start up. However until such a system is implemented and adopted by third party developers we will need to use Twitter and our blogs to get the message out.
Thanks for the heads-up.
Not being a twitter user, I don’t think it is the “closest we get right” :p Few people are on the tagging mailing list because it is notoriously high-volume. But I think that the “weekly OSM news” blogs (English and German) and the OSMF blog already do a decent job (and very importantly, encourage news submission). I read them via RSS.
Perhaps what we need, then, is a way to incorporate these specific blog posts into the editors’ message of the day. JOSM already has one, but it should
* incorporate extra sources like the weekly news blog
* only display an item once (otherwise people just click through without reading)
* allow reviewing old items
In short, it should behave like a basic RSS news reader (here’s my bias again), with a configurable list of feeds and sane defaults. And the other editors (Potlach, etc) should do the same.
Now I should stop talking and get coding…
One big driver of the way tags get adopted is its incorporation into editors. I’m not saying that is right, it it is influential. For example, Potlatch now offers oneway=no and it is (pointlessly) appearing everywhere.
This seems the best way to me, particularly in Potlatch 2 where the UI presents you with all the different possible tags each time you select an object. It prompts people to explore and think about other data they could add. In JOSM you can use the presets, but I tend to just manually add tags – six year old habits die hard.
Another is to render the results and publicise the map, to encourage people. The ITO map does a really good job on this.
I have to agree, though, that the whole tag wiki process is a mess – a consequence of people not wanting any kind of formal democratic systems, in my view – and that the oneway=no tag is stupid!
Well, I found myself in a situation where proposing archieves nothing, but simply using documented tags in mapping seems to be the right way. For example, I use “surface:grade” instead of “smoothness”, because I don’t understand the latter. And as for lane tagging, a couple months before “lanes general extension” I proposed “lanes:*” tags (in the “Turn Lanes” proposal), but it got overdiscussed and as a result, rejected by 51% of votes. But “LGE” proposal sneaked in a fictional “turn” key, and in essense being an abandoned part of “TL” proposal (which was rejected early in development because of reasons), but inflated to almost unusable value sizes and strange delimiters, it got approved not as a lane tagging proposal itself, but as an “insignificant” part of a greater proposal (and by the way, its *:lanes tags are used at least ten times less than turn:lanes tag). So I consider it cheating; it is a reason why this has gone unnoticed; and I (and a lot of other mappers) still continue to use “unapproved” lanes:* for tagging highway lanes.
So basically, right now we have two lane tagging schemes, both of which are equally spread. Supporting only one of them in navigational software would mean losing a lot of lane information for users of that software.
Ilya, it seems that you are ignoring a major part of why your proposal was not accepted: It is not sufficiently generic.
This has two effects. One is that it restricts future extensibility and mappers’ creativity. Say I want to map lane widths. With the accepted LGE proposal that’s no problem, I just use the existing width key and set a width:lanes=* tag. I can map destinations of motorway lanes with destination:lanes=*. Maxspeed? maxspeed:lanes=*. Surface? surface:lanes=*. And so on.
The other is that the generic approach allowed the LGE proposal to focus on how we apply values for a key to individual lanes, instead of getting bogged down in defining all the keys where that would be possible. That’s how it avoided the “overdiscussion” that was inevitable with your approach.
So now that we have an approach that gives us the same flexibility we are used to in OSM tagging – the *:lanes=* suffix – I hope that mappers and developers will quickly adopt it. Let’s leave the confusing situation with dozens of different experimental lane mapping solutions behind.
@Ilya, I know that, and that’s also why the OsmAnd developers came to ask it. I couldn’t reply on their question on what tag to use. The non-approved tag was used more than the approved one, and I didn’t like the approved one in particular (I don’t like long values with strange delimiters, such as the opening hours).
I suggested they should just start using one, and hope OsmAnd is big enough so it has some influence on the mappers (making a hen and hoping it gives you an egg).