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.

Hide this comment

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)

Hide this comment

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 :-/

Hide this comment

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.

Hide this comment

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.

Hide this comment

Comment from kucai on 15 October 2017 at 01:32

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

Hide this comment

Comment from Viking81 on 15 October 2017 at 20:26

@kucai what do you mean?

Hide this comment

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).

Hide this comment

Leave a comment

Parsed with Markdown

  • Headings

    # Heading
    ## Subheading

  • Unordered list

    * First item
    * Second item

  • Ordered list

    1. First item
    2. Second item

  • Link

  • Image

    ![Alt text](URL)

Login to leave a comment