Tagging practice and ever-recurring undiscussed Wiki edits

I’ve heard (esp. intermediate) mappers complain many times about that. And it makes sense. How are they supposed to map stuff if the documentation doesn’t agree with what the community expects?
NB: I am not talking about any particular instance of misleading information, just that such people exist and we haven’t worked out a solution so far.

The fact that “the Wiki may be wrong” is not usually a problem because if someone maps something and it doesn’t match what the (local) community expects, someone is going to tell them and everything is going to be fine.

It is only a problem if (a) people embark on grand “correct the world” crusades believing the Wiki gives them the authority to do that, or (b) people have a problem communicating with the (local) community. Both (a) and (b) would be problematic even if the Wiki was always right!

1 Like

There’s also a “(c)” - where there isn’t much of a local community. When well-meaning but problematic edits occur the time for them to be noticed varies hugely by region - in (for example) some parts of south-east Asia they’d be spotted really quickly; in some other places not so much.

1 Like

It’s also a problem in cases where people mass create articles for low usage synonyms of approved and widely used tags, because it causes other wise well meaning editors to use that tag instead of the approved, more popular one. Therefore eating away at a tag most everyone agrees should be used. Plus, it’s always a massive hassle to deal with. While anyone can create an article for and recommend a zero usage synonym of a popular tag, it takes an inordinate amount of time, hassle, and general abuse to either depreciate the tag or otherwise clean up the issues that it created.

It is what it I guess, but the way things currently are it’s way to easy for a person to run rickshaw all over the Wiki then it is to deal with the damage it causes. Sure, you could handwave that by saying “well, brouhaha any tag you like sir!”, but there’s clearly a difference between someone using any tag they like in their own local community versus them documenting and recommending every random, zero usage synonym of commonly used tags like tagging is a blind folded power ball lottery game or where tags are pick out of a hat or some nonsense. Either way, it should be much harder to create and edit articles to put whatever random garbage someone wants to put in them, and easier to deal with when it occurs. By easy, I mostly mean less vitriol being throwing at the people dealing with it, but it could also be easier in other ways. Like the administrators dealing with clearly bad actors and the concern trolls who enable them.

At this point someone can spend 6 years straight mass creating articles for random synonyms of established tags, calling everyone they deal with a retard in the process, repeatedly edit war them, accuse them of sabotage multiple times, and the admins don’t do jack about it. But the second someone adds a possible synonym template to an article or depreciates a tag they get attacked and publicly dragged through the mud and treated like their the bane of the platform.

The whole thing is backwards and favors bad documentation. It also doesn’t encourage discussion on either side of the equation either. Why would someone discuss an edit before doing it if they think everyone is just out to sabotage them or if they are attacked by multiple people the second they do something? Let alone why would anyone bother discussing things or even editing the Wiki in the first place if all the admins do is sit on their hands for multiple years while there’s clear instances of verbal abuse towards good faithed editors and edit waring repeatedly happening?


As a relatively new mapper myself, I feel like the wiki could do a far better job telling readers when it’s documenting how a tag is used and when it’s documenting how it should be used (according to whom?), and also that major edits are meant to be discussed first. This is something you don’t quite realise when you just occasionally read a wiki page.

The wiki is often the most obvious place to find out how to tag something, and information there is often presented as though it was widely accepted truth even when it isn’t. So I wouldn’t blame people when they think that the wiki is a more authoritative source than it really is


It sort of already does that via the status field. When an article links to an accepted proposal, the documentation will be (partly) prescriptive. If the tag is marked de facto the documentation tends to be well-monitored and generally fairly prescriptive (which barring exceptions will be aligned with the majority of actual use). For in use tags, the documentation tends to be more a reflection of actual use.

There is always a balance to be struck between documenting actual use and documenting correct use, but on the whole the wiki seems to manage this fairly well.


Thanks, I didn’t know about that subtle difference.

I agree that the status field is helpful but it’s easy to overlook. In my view it wouldn’t hurt if each wiki page had a big banner at the top saying something like “This page attempts to document how this tag is used. It may contain errors or be outdated.” or “This page documents community consensus on how this tag should be used. Please do not make major edits without first discussing your proposed changes in place X” New pages would be given the former by default.


Personally, I’d add the warning the other way round! Wiki pages that tell people how to map without reflecting actual use tend to be the bigger problem.

OSM’s Wikipedia pages are supposed to be documentation. If a couple of dozen people think that using another tag for a concept in OSM, they are perfectly entitled to express their opinion and tag things how they like.

As an example, there are a small minority of people who think that the OSM “landuse” tag should only be for actual commercial or other use of the land, and “landcover” should be used instead in some cases. This isn’t a major problem, and usage is small enough that people can deal with it.

What is more of a problem is people saying “no, you’re all doing it wrong” as a result of a poll of a couple of dozen people. OSM has succeeded because people didn’t have to confirm to a set of tagging rules created beforehand - the other projects started at around the same time as OSM have mostly failed.


The problem there is that is the status field is completely arbitrary. I’ve tried myself to get what status should be used when clarified but the conversations never go anywhere. In the meantime it seems to mostly come down to personal preference. There’s also no connection what-so-ever from what I’ve seen between how the article is written and what the tags status is. At least baring there being a successful proposal for the tag, which tends to make the article lean toward it being more prescriptive in with the proposal, But you can change the status of a tag all day without having to edit the article to reflect the change in status. Maybe that should be a requirement though. At the end of the day people probably shouldn’t be able to change the status of a tag from proposed to de-facto on a whim or without it being reflected in the article somehow.

Yet somehow people are attacked and have their edits reverted on a near daily basis for not confirming to those tagging rules :man_shrugging:

At the end of the day if the Wiki wasn’t to some degree authoritative there’d be zero point in having it. The idea that it solely exits to be descriptive and not to control or otherwise effect how people do things is just laughable. Maybe that’s the case in theory, but it definitely isn’t in practice. People often use it as a first and last reference on how to tag things and cite it in disputes. Acting like it’s an amorphous blob of documentation that has zero sway in anything just or meaning outside of being an a moral description of tag usage just perpetuates the problems people have with it.

The wiki is a lost cause. We need better tag documentation, ideally done on a pull-request model, and edited by people who know what they’re talking about rather than by anyone who can spin up 15 sock puppets for a wiki vote. Basically the switch2osm model but for tag documentation. If I had the spare time I’d do it.


This! I’ve made my employer move from Confluence documentation to a custom git-based solution and we’ve never looked back. Not only does it limit who can actually change something, but it also ensures that a second (or third) pair of eyes goes over every change.
The only problem is that someone would really have to have a lot of time at hand to implement this. Bummer.

1 Like

This risks repeating the situation with openstreetmap-carto whose core maintainers “know what they’re talking about” which really just discouraged outside contributors, other maintainers and resulted in stagnation.

The Wiki editor community is somewhat hermetic; the reasons for that might be that it did not have a visual editor for much of its life, requires another account (“normal people” seem to hate this) and also blocks registration from many IP ranges (like T-Mobile in Poland) to prevent spam but also discouraging legit users in the process.


I shall be slightly circumspect in what I say here, but I think openstreetmap-carto is basically just a case of “be careful who you appoint as your maintainers”. There are thousands of projects out there working successfully on the pull-request model.

1 Like

A centrally controlled model also has it’s disadvantages, it potentially leads to a system even more dominated by European and North American standards as it is already the case. In all fairness, it happens almost never that someone spins up 15 sock puppets and decides alone, usually there will be 15-20 people voting who by all probability are actual people interested in the subject (and well known from their interactions with the community), and yes, sometimes they make decisions that one may not agree with, e.g. tag renaming and deprecation without actually changing anything if not the tag names. Overall, the wiki is not only the best documentation we have, it also typically documents how tags are actually used (for real). There may be some errors, and it is a moving target changing every day, still it somehow works. Sure, you have to know how to read it, (e.g. sometimes check the history of the page to get a more accurate picture) and you cannot blindly trust the information.


yes, but they are all very limited in scope compared to creating a tagging system to map the whole world, not just your own surroundings.

1 Like

The wiki isn’t perfect, but calling it a lost cause is unnecessarily hyperbolic and frankly neither useful nor very respectful to the editors (both regular and occasional) who work on it. For most in-use tags the wiki actually does a decent job, with tools like ID, JOSM, and TagInfo all hooking into it and making it a readily available knowledge base. There are a bunch of editors who do a good job of keeping the documentation up to date and useful.

You could switch tech-stacks, and still face the same issue of needing maintainers and editors who can improve the documentation.

And don’t forget that wiki editors also frequently pick up valid in-use tags with 1000s of uses without any form of documentation at all, analyse their use and intent, and provide at least some basic documentation on it. Most of the wiki edits are not controversial at all.

(Leaving aside the proposal process which isn’t really functioning well.)

This already is the case. If you’ve edited a few pages you’ll notice any edits made afterwards to those pages in your watchlist. This is in addition to the handful of editors who monitor the general activity feed.


I stand by calling it a lost cause. I lose track of the number of times I have had to rewrite code because someone has decided, without consultation, to unilaterally rewrite the definition of a well-established tag.

This isn’t new. One example from the earlier days of OSM is when someone decided to redefine all barrier= tags as implying access=no unless access tags were present. This is self-evidently ludicrous in many cases (barrier=bollard preventing pedestrian access?) but, more to the point, was done post-hoc after the tag had been well established. This led to a whole bunch of unnecessary confusion, ambiguous OSM objects, and acrimonious debate - you can find the thread on the mailing lists if you like.

There was a similar situation with edits to the highway=cycleway page substantially redefining the tag. I’m not picking on whoever made the edits (I don’t remember who it was and I’m sure it was in good faith) - no doubt they had their reasons. The problem is that the wiki facilitates and, in some ways, encourages such changes.

There are tagging guidelines pages that represent nothing more than one person’s view, but lure the unwitting newbie into a trap when they break data based on reading a source they thought they could trust. People have wasted hours, and made the map worse, reclassifying roads in the US because someone decided to write a “How to Align OSM highway Values with Functional Classification” page or similar. They then get barked at in changeset comments for breaking the map and wonder what they’ve done wrong. Another instance was when someone decided to deprecate tags like highway=footway (!) in the UK purely because of personal preference.

The wiki might be useful as a drafting pad for hashing out new tags, though even then I have my doubts as it prioritises professional tag-fiddling over actual subject knowledge. It might be useful for documenting niche tags that are used by comparatively few data consumers. But as a core tag reference, for new editors or data consumers alike, it’s absolutely a lost cause.


you can’t compare the situation of the early days with today. In the early days, you really could change definitions of “important” tags and nobody might notice for a long time (and most tags weren’t codified anyway and were difficult to find because templates were used to a lesser extent), today there are many eyes on the wiki and if you make important changes to tags in significant use without consultation, chances are high it will get reverted if it is disputed. To give an example, say someone operates a business which has vital interest in some cyclespecific tags, I would expect them to monitor the relevant pages and raise the issue if someone makes dubious edits to these definitions.

Regarding your example of the barrier-tag “default”, I do not have the impression this general “no”-definition has stuck, so somehow it did work out and things have been fixed. It may have been timeconsuming to find an agreement and document it, as discussing things is always more onerous compared to having a hierarchy of a few decision makers who decide for everybody and no questions taken, but the hope is that the result is more appropriate for our setting and values.

1 Like

No, the wiki is not ideal. Yes, the wiki provides enough detail and redundancy to be useful when making up my mind how to map things. Especially in combination with taginfo, the usage status, quality control and quality assurance tools, the built-in history, and the communities.

If I thought the wiki were authoratitive, I would often be disappointed. If I thought the wiki were purely descriptive, I would often be disappointed. As it is, it’s a mix and you have no guarantees, you can’t trust it blindly. It often means there is a bandwidth of options, so I have to think about it, look around, ask around, then make up my mind and decide. Decide which way to go, or decide do spend my time on something else.
The fact that the wiki can’t be trusted blindly, actually helps to move OSM mapping forward, keeping mappers, data users, renderers, developers and users on their toes.


It is absolutely still a problem with the wiki now that tag definitions get changed there that does not reflect usage. A “someone is wrong on the internet” mindset is very much normal human nature, and it’s actually quite hard to put that aside and try and look at things more objectively.

The advantage that a pull request model has is that everyone gets to discuss it before any change is made. There have been attempts to do this - here is one; here is essentially another. The latter has many of the same sort of contentious submissions as the OSM wiki but there’s a filter that ensure that changes where we (as a community) “just aren’t sure” don’t get applied.

The challenge is that it’s significantly more work to do that than “just editing a wiki page”. I look after some of the pages at https://switch2osm.org/serving-tiles/ and know hard it is** to make sure that that is “not wrong”, before even worrying about the things that it’d be nice to have there that aren’t there currently.

** The last series of updates here, here, here, and here needed many weekends of testing, software debugging, writing munin scripts that didn’t already exist etc.