Why is Nakaner not in favour of your proposal?

Posted by Nakaner on 12 October 2017 in English (English)

no and yes vote icon of OSM Wiki votings

From time to time I participate in the voting of tagging proposals. Even if I lack the necessary knowledge in the field the proposal is about (e.g. I have limited knowledge about electricity or fire hydrants), I check a few things before I cast my vote. (The following is my personal opinion)

Avoid changing heavily used tags

A proposal should always avoid to change existing tags which are used a lot. There are some reasons for a change of the tagging but they are rare. Changing American English to British English just to have British English is one example if there is no other benefit. Changing from or to namespaced keys/values is another.

If the only reason is to have nicer keys/values, this will just lead to an unnecessary workload for multiple parties. Mappers who attempt to do mechanical edits, other users who revert them, the Data Working Group who has to mediate disputes (or has to revert the changes if it has not been done already), and last but not least data consumers who have to change their software. You might think "Data consumers, don't be angry, you have just change a string (and add an AND to your code)" but you should keep in mind that more and more data users order pre-installed servers/services from companies in the OSM ecosystem. Their services get automatic data updates because they want or need data being up to date but they will miss more and more features. And all this just happens because someone thought that an l is missing in jewellry (I am not sure if that was a joke or test).

If a proposal tries to change a heavily used tag, I think that it has to address why this change is really necessary and that the "cost" of the change are lower than the benefits. Mentioning this only in one or two sentences will lead to a failure of this test (except very long sentences). If a proposal fails this check, I will say NO although other parts might be good.

Well formed keys and values

If check number 1 is passed, I will check if the new tags and values are well-formed. Keys must only contain lower-case characters, underscores and, if really necessary, numbers. Colons are namespace delimiters. You must have really good reasons that I accept upper case characters. Spaces and other characters are a no go.

The same applies for values. Only free-text values may have any content.

Boolean values must be no or yes.

This check must be passed, too. A failure results in a No vote.

Good tag design

Good tag design is more difficult. It is a good idea to put special interest tags into a namespace but on the other hand namespaced keys exclude mappers who don't think they are qualified to edit them.

Namespaced keys have the advantage of avoiding conflicts with other keys which could be tagged on the object. On the other hand, namespaces add some kind of noise to the raw tag list.

Using keys to tag properties of the new feature B which are already in use for feature A is not a good idea if an OSM object could be both A and B but the value of the key should be different.

Example: A pole of a power line (power=minor_line) has a reference number ref=34. A proposal wants to add a tag to map transformators on poles. Both should share one node in OSM. Adding the reference number of the transformator as ref=T5 is not possible because this would overwrite the reference number of the pole. Adding a special tag for reference numbers of transformators mounted on poles is one solution. The other one is to map two nodes. Both have advantages and disadvantages.

This example shows that there is not always a clear answer what good tag design is and therefore serious problems have to persist after the discussion to make the proposal fail this test.


A tagging proposal should only suggest tags which are observable on the ground. For example, a proposal which contains a tag for the maximum amperage a electrical locomotive may consume from the catenary, might fail this test if the author could not point me to a region where it can be observed on the ground (in Germany you cannot observe it).

If a property or feature can be observed only on some objects, this will not cause a failure of this test.


Tagged values have to be stable. If values changes multiple times per year (or even every year), maintenance is difficult or impossible. If the value changes too often, the property does not fit into OSM at all.

This is a soft fail test, too. If the properties of some instances could be stable but other are not, it might not lead to a No vote.


Tagging proposals which invite mappers to add information which infringes privacy and/or will lead the project into legal trouble in regard with data protection (in Europe) could fail this test. It depends on how much tagging without infringing privacy is possible (see "Stable" and "Observable").

For example, a proposal with a tag for the owner of a house will clearly fail this test.


This is a soft test. Readers of a proposal should understand quickly what the proposal wants to change, what it introduces and what is just mentioned as context to understand the proposal. Guides which summarize various tagging schemes fail it easily because proposal are not guides but change requests. If a guide covers a disputed topic, it is a good idea for its author to write that it is disputed, what the parties arguments are and leave the decision to the reader.

Split up your proposal into a section of simple and advanced tagging if your proposal is very long and goes deep into a topic of a special interest. People starting adding the simple features and properties might later use the advanced tagging. But if you only offer a steep ladder, less people might climb it up.


As you have seen, I am very strict because there is no difference between a YES and a partial YES. But you, as a proposal author, could circumvent this problem partially. If you split up your proposal in two or more parts, the parts which don't fail these test, will pass.

If you want to learn more about how to write good proposals, I suggest you to read the discussions and voting section of rejected proposals.

What do you check if you read a proposal before you cast your vote? Or does your wiki user page already include the UserAgainstTagVoting or No_Wiki_Fiddlers template?

Comment from Warin61 on 12 October 2017 at 23:45

Read through this the saying "Rules are for the obedience of fools and the guidance of wise men" springs to mind.

Taggs with large use do get changed .. look at the public transport version 1 and version 2. things do evolve over time.

Then there are tags that are the result of imports. The present 'airstrip' is from a New Zealand import that IMO should be tagged aeroway=runway surface=unpaved rather than creating a new tag (that have not been voted on). There are some 3,500 uses of this poor tag.

The tag fire_hydrant:diameter= (which has never been voted on) should be altered to the simple property tag of diameter=* (again not voted on) to comply with the present property tagging practice.

With the present difficulty of voting tags into acceptance there is a distinct lack of any advantage of proposing new tags, it is simply better to induce them without any discussion, or if discussion takes place locally it lacks any international view. Users against tag voting contribute to this. And this will mean more and more junk tags being introduced.

Comment from escada on 13 October 2017 at 06:29

@Warin61, do you seriously want me to spend time to retag all 1978 fire hydrants I mapped [1] in the past, just because 10 mappers decide that fire_hydrant:diameter is not hip anymore and has to be replaced with diameter ? Do you think I have nothing better to do ? I would rather map another 1978 fire hydrants, than retag the ones I mapped. I noticed you mapped 6 fire hydrants in Sydney, that is a totally different scale

Of course I could use Overpass + Level0 to do the retagging in a few minutes, but still it is a waste of time IMHO.

So I totally agree with Nakaner's "Avoid changing heavily used tags".

[1] (by the way all surveyed in case you wonder)

Comment from escada on 13 October 2017 at 06:39

p.s. Luckily the proposer of the new fire hydrant tagging scheme mapped 1095 hydrants so far. At least s/he would feel to remapping pain as well :-/

Comment from Warin61 on 13 October 2017 at 07:10

@ escada Surprised I have mapped that many fire hydrants? Probably I have retagged anothers work locally for currently correct detail. I am reluctant to fire hydrants unless they are usefull to my local fire brigade - they may already have them. I am yet to go and ask. If they don't have that information then I'd be inclined to map them around the local bush, together with the SWS (Static Water Supply) which I expect are not mapped anywhere, nor does there appear to be a usefull OSM tag ... so I'll probably make one up without any discussion ... cannot be bothered with the pain.

I am not proposing that retagging be done by the original mappers, nor that it needs to be done quickly. Look at the public transport version 1 to version 2 ... will they all be migrated in a year? Or in 10 years? The point is - which is preferable in the longer term?

I too would rather enter new usefull data. But I would rather enter it using tags that make sense and will stand the test of time. So I enter new buss routes with version 2 data, I update the old version 1 buss data - keeping it version 1 due to the work load but keep it current with route changes.

Yes, it is good to avoid tedious work that really adds nothing other than future order and eases future beginners learning. But for the benefit of new people it may well be worth doing.

Comment from Viking81 on 13 October 2017 at 22:51

@ escada Well, for me it will not be a pain to retag my hydrants, if it brings to a more logical structure. And with overpass it's quite easy. I am spending more time trying to explain our reasons than it would take to retag all 400.000 fire_hydrants:diameters=* all over the world.

@Nakaner We can go on splitting and splitting, but I suspect we will go in a neverending story and I'm loosing confidence in the voting process. Instead of simply voting no, why don't you help us with further improvements? Some things can be adjusted or explained better in the final wiki page, but you can't wait in silence that we do all the hard discussion work and then jump out only to the vote and expect that we rewrite all because it doesn't match your standards. Please be cooperative, not obstructive.

About the namespace, even you admit that there are reasons for removing them. In this case there is not the problem of having on a hydrant node another feature that requires diameter, pressure, or location. A hydrant should have a node for itself only.

Why should we continue to use fire_hydrant;pressure, if pressure already exists and it's simpler? Tomorrow when pressure will have its own detalied wiki page, someone can read it and use it on hydrants. The same with diameter and location. So in future we will have some hydrants with namespace, and others without it.

Instead if we do now the simplification, tomorrow all hydrants will have homogenous and simpler tags. In the long term, simple is better, and for me this is a good reason to change all 400.000 recurrencies, obviously allowing a transition period when old and new tags coexist, to allow software adjustements.

Comment from kucai on 15 October 2017 at 01:32

Can we just bypass this "tagging freedom" thing and just create an approved list?

Comment from Viking81 on 15 October 2017 at 20:26

@kucai what do you mean?

Comment from escada on 16 October 2017 at 05:12

@Viking81, as Nakaner wrote, it is not only the hundreds of mappers that have to go through the pain of remapping there stuff, it is also all data consumers that have to add code to use "pressure" besides "fire_hydrant:pressure". This means creating issue cases, planning, them, developing them, testing them, releasing them and maintaining them without any improvement for the end consumer. This is something each development team hates (I know, I do software development).

You want to change fire_hydrant:pressure to pressure and look for 10 other mappers that agree (and hopefully no one objects). There is no guarantee at all that there won't be a group of 10 other mappers that will do the opposite within a couple of months or years. Just renaming tags is such a waste of time & resources.

I wish OSM had something similar to Wikidata. Wikidata abstracts the tags away. The have P. Then you can name & describe it however you want, you can add synonyms, translations without any problem. For the all data consumers it remains the same P

I think people assign too much value to how a tag is written. For me there is no difference between pressure and fire_hydrant:pressure. It's the same. I would happily use one or the other, but there is no reason to replace one with the other.

Another drawback is that you just make the database bigger with another version that is just replacing a tag with a synonym. Whoever is using a template in an editor will hardly notice what the actual tag is, so why would they find "pressure" better ?

BTW, I didn't vote, because the voting process is no longer working. There are too many different opinions that do not participate in the discussion, and only vote. Or the voting group is not represenative for the community as a whole. I don't have a solution for those problems. I just vote by using tags (or using the tags my editor gives me).

Comment from cm8 on 24 October 2017 at 09:25

Once upon a time OSM prioritized the community aspect over data quality (!)

In this regard here it essentially means that we do not care about data consumers, if and only if a majority of the community reached a consensus to change heavily used tags.

This is necessary for two reasons:

(1) Tag finding is a rapid process and it is easy to introduce quirks and misnomers that may spread out to being widely used ''before'' the majority of the community notices that there's a better tag to be used (producing less work in the long run, because it has less conflicts with other tags).

(2) If OSM is to avoid fixing long standing design flaws (which this proposal is essentially about), it will be trapped by inextensible map features in the future:

Most of the time, people seek to change and namespacify existing tags, because they ''have used'' them for a very specific feature, without noticing that the label of the tag denotifies other objects as well. -> Often this is noticed and accomodated to at times when the tag is not yet in widespread use, but there are exceptions.

Fixing these exceptions has a larger impact, yes. But the reasons to change these are just as valid as to change tagging flaws with lesser impact.

Being convenient about this may very well hinder growth of the data model at a later time (or lead to overly complicated new tag creations in desperation to circumvent the limitations presented by tags used in the wrong place ''then'').

To actually ''fix'' and improve such a situation in OSM, it ''must'' however strictly be a community effort and well documented. There's no use in fixing tag labels and documentation if the reason to do so is not widely understood and supported. Of course (and unfortunately) the latter implies some feedback to the couch potatoe crowds which Nakaner's arguments have in part fallen victim of:

The DWG mediating disputes (or generally reverting changes back and forth) is a ''result'' of poorly discussed, communicated (and hence supported) tag changes. Advancing to this (potential) result of an effort to improve the map features must not be presented as a ''reason'' to give up on such effort.

Comment from escada on 24 October 2017 at 09:35

@cm8: please tell me why "diameter" is better than "fire_hydrant:diameter". I have not heard a single argument that convinces me. What is the quirk, misnomer or bad use of namespace in this case? Is it really a fix or improvement ? Why do we need it to be called diameter ? Why is it better for a mapper to use one over the other.

Why do I have to learn a new mapping scheme ? Is that taking care of mappers ?

Comment from cm8 on 24 October 2017 at 10:06

@escada: I did not delve into the fire hydrant proposal. My reply mainly deals with Nakaners generalization ''to avoid changing heavily used tags'' (which is not specific to the fire hydrant proposal).

I personally think that people should decline voting on proposals that they are not concerned with. If people do not map, tag and understand objects of that realm, their judgement is impaired or lead by secondary reasons and, most of the time, unrelated to the main issue.

That said, I do not oppose exchanging secondary viewpoints and bringing them to the awareness of proposal authors, but they should remain what they are: secondary issues. And they should (ideally) be raised during draft, not during voting. (I think that was a main complaint of the author(s) for the fire hydrant stuff).

If a proposal really is not an improvement (or if it has to be reworked), then there are better arguments to disapprove it than saying "it's inconvenient to adopt to". This is a foolproof argument to disapprove ''any'' change, regardless of its usefulness.

Comment from cm8 on 24 October 2017 at 10:20

@escada: To try to understand why "fire_hydrant:diameter" was chosen over "diameter" I can only speculate (I usually do not tag these objects).

Maybe "fire_hydrant:diameter" specifically means the diameter of the water pipe within the hydrant, while "diameter" (a general object tag) simply means the true diameter of the fire hydrant?? In pretty much all cases these are two different values.

I'd guess that the value to this tag is currently useless, because you do not know whether mappers tagged the true diameter or the pipe diameter. You will note, that useless means, data consumers will also process useless data. So indeed, fixing the tag in this respect may actually be of more value to data consumers than leaving it in its useless state. ;-) But it's just my guess. Usually fire fighters are not that dumb to rely on data they have not mined themselves (let's hope they are not).

Comment from cm8 on 24 October 2017 at 10:48

@escada: I agree with you in that "fire_hydrant:diameter" and "diameter" may not be self explanatory (which in general is desirable when chosing a tag name). For example, if the valve diameter of the fire hydrant was meant, then "fire_hydrant:valve:diameter" should have been used. Making a decision between the former two without documentation is error prone (you do not really know which one to use for the true object diameter).

So yes, in that respect the fire hydrant proposal may not have been perfect - and its a much better argument to disapprove it or demand rework than choking it off with a heavy use of prior art argument.

Comment from cm8 on 24 October 2017 at 21:36

After rereading (and recalling) some key points of the fire hydrant proposal, I consent with Nakaner in this case. The proposal seriously needs rework. Instead of degrading tag names to be ambiguous (again?) it should have proposed further refinements to resolve ambiguity in tag names (if and where needed).

However, iterating on the above, please do not generalize disapprovals using arguments like avoid change of heavily used tags, this is too unspecific to be useful. It does not help proposal authors to understand why or where they failed and it potentially discourages people to propose changes in areas where change might indeed be useful to the community.

Comment from cm8 on 24 October 2017 at 22:10

I think the reason they tried to move "fire_hydrant:diameter" to global namespaced "diameter" (and similar tags) is lying here:

pipelines use diameter and pressure without a namespace bound to the object. While dealing with potentially lots of diameters on a fire_hydrant, a pipeline is assumed to only have one of importance (presumably the outer diameter, together with the wall thickness an inner diameter may be deductable).

So maybe (this is just a guess) the intention was to streamline the usage of diameter and pressure for pipeline and fire_hydrant objects. But in this case this might have also been achieved by proposing "pipeline:diameter" and "pipeline:pressure" on the man_made=pipeline side of things.

Comment from Viking81 on 28 October 2017 at 22:27

diameter=* in combination with man_made=pipeline refers to the NOMINAL diameter of the pipe, that is related but not equal to the inner diameter. It is documented on pipeline and diameter wiki pages.

In case of fire_hydrant:diameter it is again the NOMINAL diameter of the hydrant, that is often printed on it and it refers to the flanged connection to the underground pipeline. Again it is documented on hydrant wiki page.

Anyway I gave up on changing that tag, it will reamain as it was before, for better or for worse. We need to go on with the other new tags, so please see the new proposal here:

I and all the people that worked on the proposal would like any comments to come out BEFORE the beginning of the vote.

Thank you


Login to leave a comment