OpenStreetMap
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.
Discussion
Comment from Richard on 4 January 2015 at 12:47
Agreed 99%.
The 1%: I don’t think it’s data consumers who are responsible for this mess. It’s tidy-minded people trying to second-guess data consumers. If these tidy-minded people had actually used OSM data they wouldn’t be coming up with batshit insane proposals.
At cycle.travel, I suspect I do more detailed analysis (for both routing and display) of paths than any other data consumer. The two most notorious wiki-inspired tags, highway=path and smoothness=, haven’t made life any easier for me; they’ve made it a whole lot more difficult. When highway=path is used without a vast array of supporting tags, which is the case the majority of the time, it’s impossible to guess sensible defaults. smoothness= is just a plain bad tag in ways which are too numerous to recite.
Or in other words:
Comment from imagic on 4 January 2015 at 13:10
@Richard: You are right. I took a short cut there when writing as it got already too long.
In my opinion, the pressure comes from the consumers, but not only directly but also indirectly. Indirectly by - as you call them - tidy-minded people, who want something supported, so they write something, force a vote and then expect instantly all consumers world wide to support this, especially after they added those three nodes with the new tag in their home town. And the consumers HAVE TO support it: it is approved!!!somemoreexclamationmarks!!
Comment from chillly on 4 January 2015 at 17:47
I agree that voting is (and always has been) a stupid way to proceed. There are no approved tags, so how can any one vote to approve a tag or tag scheme?
I agree with Richard. I do not agree that consumers drive the approval process. Data consumers quickly understand that all OSM data needs parsing before it is used, either as it is loaded into, say, a database for use or as the data is actually used. This allows any grouping of tagging to be made, for example in one render I have I’m only slightly interested in landuse so I group landuse=residential, retail, commercial, industrial etc all as the same render. It’s easy, I only write the code once and use it any time in the future I want it. Tools like osm2pgsql with the ability to pre-process with LUA is a good example of this process. OSM data is often combined with data from other sources, such as elevation data, other open data or private data. This will never be in OSM format, so processing to combine them will always be needed.
Wiki fiddlers usually don’t seem to understand this at all.
Some of the tags proposed are simple, useful and should just be used. So no voting is needed, only documentation so other people can choose to use the same tags. Some tagging schemes are not simple at all, sometimes producing a rival scheme to an existing set of tags. Then data consumers have to deal with both schemes. That’s not too hard, write the code once and use it over and over. The real problem is that mappers are then confused and some take up positions in rival camps. Mappers are out most precious resource, anything that confuses them is A Bad Thing.
I feel most of the tag approval process is well meaning, but the idea that simply ‘voting’ to ‘approve’ a change to an existing tag scheme means that must be adopted is short-sighted and even arrogant.
A mass edit, justified by a wiki vote, is not something I like. We want OSM to be used. Not all OSM data consumers follow OSM closely, indeed I’d hope that they don’t need to be glued to OSM. They won’t follow the minutiae of the mailing lists or wiki (who can blame them?). Hacking around with existing tagging schemes that is then implemented by a mass edit is going to break the system used by some consumers of OSM data. They will fix it, probably fairly easily, but not before their broken system has been noticed, reported and reduced the confidence in OSM data both by the data consumer and their clients.
The voting system has been criticised for years. What do we need to do to remove this damaging process?
Comment from imagic on 4 January 2015 at 20:03
@chilly: Thanks for your comment. Regarding wiki fiddlers and documentation I want to add one more remark: Why do we need a status for a key? Why is it necessary to get a glowing-green “Approved” on a wiki page? Why is “Rejected” hellish-red? Those details support the impression, that only good, green, approved tags should be used, that they are official tags. This is not true and we should start with removing the status from the wiki. The usage numbers from taginfo are all we need.
Comment from Warin61 on 4 January 2015 at 22:18
I’m come from Australia, where voting is compulsory. History shows that less than 5% don’t attend and less than 5% are ‘informal’ (not filled out or incorrectly filled out) so less than 10% don’t effectively vote. Voting rates for OSM proposals are much much less .. and many fail due to lack of votes .. less than 40 people are making things ‘approved’!!!! Get off your bums and vote - that way ‘we’ might get things ‘approved’ rather than ‘rejected’ simply because they don’t have the required minimal number of votes….
Maybe along with the green ‘approved’, red ‘rejected’ we also need an orange ‘apathetic’ classification.
Why do things need to be ‘approved’? I’ll take ‘radio telescopes’ as one example.. There is a current project to construct a ‘square kilometer telescope array’ by an international consortium. The have chosen to split it into two arrays (of differing reception frequencies), one in Africa the other in Australia. The people in Africa are using one tag, while the people in Australia are using another … neither is ‘approved’. None of the renders I use display them. If both used the same tag and the other tagged radio telescopes were also appropriately tagged and it was ‘officially approved’ then there might be a better change of it being rendered…
Comment from gileri on 4 January 2015 at 23:07
@chilly, I think it’s a circular problem. Data consumers try to do something with the tags already used, and people, seeing that a certain tagging scheme is used, so they continue tagging stuff using that.
The problem is that often tags were introduced with low detail & complexity in mind, which regularly hinders data completeness of a feature (I’m thinking highway=bus_stop vs Public Transport) As described in the first paragraph, people would never go out of their way and use more complete or precise tags, as long as data consumers does not force them to use better tagging scheme.
The only way people could be encouraged to do so would be with votes leading to approved tagging schemes, but sadly, taginfo stats often wins over well-defined tags.
Comment from Warin61 on 4 January 2015 at 23:49
Anarchy? There are at least 12 tags in use for ‘tap’ as in the common water tap … when would ‘you’ make the decision to bring them all together? Years? Decades or centuries? Note how long ago the proposal for ‘radio telescope’ was made. And who decides what is the better tag? And who then does the work? And will the renders agree, or possibly stick with their probable previous decision/s?
Vs voting? There is currently a proposal for the tag ‘tap’ as in common water tap. There are presently at least 12 varieties in use. The proposal could bring them all together. Yet only 3 people have voted. Discussion has taken place with varieties of hot/cold/portable/boil for portable/constant flow/etc. That has delayed the vote and confused the issue. Rather than let people have tags for each would it not be better to guide them into sub tags .. using an ‘approved tag’? Voting on any sub tag would take placed after the ‘tap’ tap approval. No approval = no point in taking about hot and cold taps… At least with the tagging group their is discussion and possibly a concensius, while leaving to an individual tagger means OSM gets lots of differing tags all meaning the same thing.
Comment from pnorman on 5 January 2015 at 08:11
With the exception of a few foundation-related matters (board elections, some WGs, etc) we don’t use voting in OSM. You don’t need the authority of a vote to tag a way, and there’s no requirement to follow what has been voted on.
The part of proposing a new tag that has value is explaining it to others.
Comment from escada on 5 January 2015 at 09:19
@Warin61:
Re Voting: maybe most people on the tagging mailing list don’t care enough for a water tap tag ? Maybe the discussion was only about having a consistent scheme and not about the feature itself.
I wonder how many people read the wiki pages. Especially when your mother-tongue is not English. Nevertheless, when 1 of the tags for mapping water taps would be documented and would mention all other tags that are in use, it might become the de-facto standard.
But when will people use 1 tag for water taps ? When iD and JOSM use the same preset. IMHO, you should not underestimate the power to push a tagging scheme by the build-in presets of those editors. So when you want your tag to be used, do not get involved in a voting process, sneak it in in the presets of the editors. :-)
Comment from AndiG88 on 5 January 2015 at 10:23
The voting system has been criticised for years. What do we need to do to remove this damaging process?
Spend more time in the Wiki and document stuff. Create pages for values that have been used a couple of times (=> TagInfo): Use the template put up an image and a description. Look for similar tags, create a See also section etc. Also if you find similar or related tags link back from them, too.
That will make it easier for people to find tags that are in use. Help them to compare them to similar tags. Provide them with a place to discuss the differences (talk page). Reduce the risk of missunderstandings by providing a description.
If you look at TagInfo and non-documented values for amenity=, shop=, leisure= etc. you will see that tagging for one kind of POI can evolve in many different directions. One good example is gym/fitness centre, where even today people tag it in more than 5 different ways. As someone said before…
When would ‘you’ make the decision to bring them all together? Years? Decades or centuries?
That’s actually what happen most of the time. Someone proposes a good tag, because the RFC process takes to long it falls under the table, but because there is now a proposal and maybe a wiki page this tag definition can be found and used by other mappers.
Which bascially means that your idea of tags slowly evolving tags is bad. Because that means for a long time you might have different tags and a mapper might not be sure what to use and that happens far more often without any proposal involved.
The usage number from TagInfo don’t tell you if there is some general definition behind a tag or if there are similar maybe competing tags. Numbers might not says very much when they are around 50-1000. Most of the time they are only of value when you actually see their numbers compared to similar tags, but how often do people actually put that much effort into the Wiki? Ask yourself: How often have you done that?
Editor Presets
If there is no agreement on a tagging schema then editors can’t provide casual mappers with presets, which probably results in less stuff being put on the map. Especially people using something like WheelMap will not look into the Wiki on their Smartphone.
Translations
Some native English speakers here might not realize that at least in Germany we have a lot of mapper that aren’t that good with English and I have to say even I don’t know all the stops and crafts.
So just waiting for one tag to evolve means much more work for people translating stuff (now you need to translate every wiki page) and less tags being used, because nobody bothered to translate any of the competing tags.
In addition it can cause errors, because of false friend translations, for example fireplace translated as “fire” & “place” would probably be interpreted as an outside place where you can make a fire and not a architectural structure.
Coming to agreements early, documenting it and not waiting years for something to evolve will help to reduce errors here.
Comment from imagic on 5 January 2015 at 10:44
@Warin: Regarding the radio telescopes: there is no “officially approved”. Do you really think, that a tag, that is used twice (once in Australia and once in Africa) will be supported by any consumer just because it is “approved”? If you want your tag to be supported, then do just that: support it! Talk with the mappers in Africa. Can both tags be used simultaneously? If yes, do so! You want it rendered? Did you write some documentation? Did you open a ticket with your favourite renderer? Did you prepare an image for the renderer? There is a lot more meaningful to do rather than putting an “Approved” on a wiki page.
@gileri: There are some problems with “well-defined tags”.
@pnorman: “The part of proposing a new tag that has value is explaining it to others.” VERY TRUE!
Comment from gileri on 5 January 2015 at 13:10
@imagic : Administrative boundaries are hard to map, so we should not map them badly, even if information is readily available in order to map them correctly? Some data are not trivial in the real world, and they still need to be mapped.
As you said : “it might be a horror to use for any consumer, but it is still valid data”. If a data is not usable by data consumers, it have almost zero value to OSM. OSM is not an atlas, read by humans. The OSM database must be parsable in order to be of use.
If we go down that path, why defining a format for opening hours, as humans could parse it, and why create specialized tags when we could only use name=* as it would be still readable by humans ?
Let’s not forget that OpenStreetMap is a database. It comes with responsibilities in order to deliver it’s true potential.
Comment from imagic on 5 January 2015 at 13:13
@gileri: Please stop putting words in my mouth I never said.
Comment from Skippern on 5 January 2015 at 13:15
There are unfortunately some diehard voting-nazis (yes I mean that negatively), that are quick to delete wiki-pages for tags they don’t like etc. I once had an edit-war on wiki because I suggested an data enhancement of
maxheightby addingmaxheight:physicalandmaxheight:legal, where my page onmaxheight:legalimmediately was deleted because maxheight means maxheight:legal.I still managed to create my page, IMO
maxheightis generic whilemaxheight:physicalandmaxheight:legalis equally more specific. Is there a reason to separate these values? If not than body usemaxheight, if there is a deeper reason to specifymaxheight:physical, what makes that different frommaxheight:legal? Ismaxheightthe same asmaxheight:legalin every country or does some countries differ from that rule?When working with maxheight I got the impression that (at least the guy who deleted my page) lived in a country where
maxheightmeansmaxheight:legal, while I live in a country where the two are equally different.In my opinion it is more important to document on wiki the tags that are in use, albeit in a relatively small area or by a very limited interest. Or specially in those cases.
TagInfo speaks for itself, and as every wiki-page using the templates for Key and Tag-values implement a info-box about usage inherited from TagInfo, than I find that a wiki documented tag tells more than a vote.
A vote though might be useful indicator when changes to an existing tag are suggested. It can help refine the proposal, make people aware of the upcoming change (I know you still are at liberty to do it the old way), and most importantly a signal to data consumers that changes in the data they use might occur.
Comment from imagic on 5 January 2015 at 13:36
@Skippern: “A vote though might be useful indicator when changes to an existing tag are suggested.” That’s a very good point and I agree with you. If we need - for whatever reason - change the meaning of an already existing and used tag, we should vote on it. But in my opinion the current voting process is not suited for this, because we might reach only a very limited audience.
Comment from Skippern on 5 January 2015 at 14:11
@imagic: I agree that the process is not good, it is actually horrible. And in many cases I have seen the proposal being edited several times during “the voting period”, which actually should render all previous votes invalid. I have also seen other documented tags being altered in order to affect the voting result (why should we approve this when that already mean the same (edited 3 days into the vote)).
The proposal page must be frozen before the vote
Documentation of affected tags must not be edited during vote
A significant portion of people should vote, principally those with knowledge of a specific field if one talks about deep-defining tags within special areas (such as electro-people to have much weight into what tags are useful, sensible, etc in tagging a generator)
At the moment the “status” of the documented tags take up too much space (too vivid colours, too large font type), and some people are throwing in templates for this tag have not been proposed or this tag have been rejected. The only template I find useful in this case is this tag have been deprecated by
new tagAs a data consumer documentation about the usage of tags, and the availability of additional information that can hint me to how best parse the tags is good, I like TagInfo since I can compare the global usage with my specific area of interest, what combinations are common, etc. Should I bother to make rules parsing name to a feature existing millions but only two have been named? TagInfo can tell me something about that. And a good wiki-documentation can also give me some indications there.
Comment from Skippern on 5 January 2015 at 14:16
Also, even badly documented wiki-pages using the KeyDescription or ValueDescription templates already tell you a lot about the tag usage, from there it should not be too hard to evaluate how useful it is, in what combinations it have been used, etc.
People should not be afraid of making a useless wiki-page, those templates provide enough to say, in most cases, that the documentation is at worst thin, but never useless. Complex schemes need some more though.
Comment from Warin61 on 5 January 2015 at 20:39
” Regarding the radio telescopes: there is no “officially approved”. Do you really think, that a tag, that is used twice (once in Australia and once in Africa)”
An ‘array’ as in a number of things (in this case radio telescopes) arranged into some order.
At present there would be something like 6 each tagged in both Australia and Africa, eventually there will be 36 in Australia and I expect a similar number in Africa. And that is for these arrays only - Australia and Africa have others separate from these arrays.
http://en.wikipedia.org/wiki/List_of_radio_telescopes list 100 around the world .. note that some of these are arrays .. meaning one listing is more than one telescope… They are significant navigational things in the landscape.
If it simply a question of the number of items to be mapped .. then taps would, I think, be significant in number (presently over 600 with user tags?) .. yet it has few votes. Now 5.
Comment from jgpacker on 6 January 2015 at 16:08
@imagic: 2 comments > [..] Why do we need a status for a key? Why is it necessary to get a glowing-green “Approved” on a wiki page? Why is “Rejected” hellish-red? Those details support the impression, that only good, green, approved tags should be used, that they are official tags. This is not true and we should start with removing the status from the wiki. [..]
I disagree with removing status from the wiki, however they could be better defined. The color was added recently by a user. Feel free to remove it if you believe it shouldn’t be there.
Not true. Often the usage numbers come from an import, and even from bad imports (i.e. undiscussed/unskilful).
Comment from jgpacker on 6 January 2015 at 16:11
See http://www.openstreetmap.org/user/jgpacker/diary/28266 for a related discussion.
Comment from Hedaja on 8 January 2015 at 15:36
I can understand both factions. On one side i like the do-ocracy because its is possible to describe new things no one thought of before. But on the other side I’m (like most mappers) are data contributer and data consumer simultaneously. I think if tags only evolve and introduced because they are being used, we are going to get bigger distinctions betwen the different “sub” subjects of OSM (like Railways/highways). A lot of very active mappers tend to specialize on one topic. This means that active mappers might push this topic further without the view for similarities to other things. One example is the way proposed things are tagged: for highway the preferred way to tag is highway=proposed + proposed=type_of_street and for building the slightly more used way of tagging is: proposed:building=type_of_building. Having different ways to tag similar things in different subjects makes it a lot more complicated for cross subject mappers and for people who just started mapping. If there is a clear scheme how to map similar things people would know: “Hey I have a proposed building so I’m going to tag it like proposed highways I already tagged before”. This would spare people of lot of work for searching in the wiki and on taginfo. Thats why I think some form of standardization is necessary. For example when introducing new tags do you use tag:suffix or tag + extra tag. I think for such things some type of voting is important. The way Voting works atm is not satisfying. The Voting process is well hidden in the depth of the wiki. Voting processes should be made more prominent by showing them on the wiki start page, Editors and other places mappers use. Another problem in my opinion is communication. The rich possibilities for communicating in OSM is blessing and curse at the same time. With forum/wiki (discussion pages)/ mailing lists/ IRC/ help desk/ (Changeset Comments) we have good communication tools for every need. But the bunch of places also separates users from each other. I think there aren’t so many who are watching multiple or all communication channels. Sometimes this leads to situations in which one part of the community isn’t aware of the other part, which leads to confusions. Another thing I see is that it’s really hard to change old tags because you may have to do a mechanical edit and and it’s always very hard to convince all active mappers that this won’t break everything. But in my opinion changing old tags that are used a lot sometimes might be necessary to improve OSM. In this case I think that “projects using this tag” of taginfo is very important. Data consumers should be encouraged to document their used tags so that they could be automatically notified when any changes in tagging happen. If all developers are notified in advance they would have the possibility to make their code changes and be ready for the day the new tagging starts. A defined time span and developer notification for bigger changes would weaken mappers argument that a change in tagging would break all there beloved apps and map styles. I’m aware that big mechanical edits are always critical. Just like now they should be well documented and tested.
Comment from Pieren on 16 January 2015 at 12:44
But this does not work as well. You create multiple and parallel solutions for the same problem, depending only on decision made by a few number of data consumers.
It’s true that proposals are often accepted with a low number of votes and where the result is still unsatisfactory. We can all dream about a dictator or great engineer taking perfect decisions making everyone happy but this only exists in books, not in real live.
About the low number of votes, it’s like in real democratic system. Only non-voters have to be blamed, not the one who expressed their opinion. But as I said several times in the past, the words “vote” and “approved” are incorrect. We should better say “opinion pole” and “best reply”.
Comment from Władysław Komorek on 16 January 2015 at 18:33
I think the problem lies in the fact that most mappers do not speak English. So they do not open the page “Talk”. A large group of mappers expresses his valuable views on the tagging on the OSM community “Users: ….”. So, seems to me that it would be worth it to somehow integrate the “Users: ….. / Talk”.