Wiki tag pages without proposal process

[woodpeck (Frederik Ramm)]

The tagging pages on the wiki can be the result of a proposal process, or they can be created for tags that are clearly “in use” even if they have never undergone a proposal process.

What is not ok, however, is someone creating their own wiki pages in the main namespace for their own tags which are (more or less) only used by that person. It is allowed to use “any tags you like” but it is not allowed to create official-looking tagging pages for any tags you like without a prior discussion.

I have therefore moved User:Anonymous36863/Key:diet:excipient free - OpenStreetMap Wiki (created by @Anonymous36863) into their user namespace until such time that a proposal process about that key has succeeded.

[Map_HeRo (Mikke)]

I do not want to start an argument about which newly created tags may be documented in the wiki and which should not. I just want to point out that the wiki itself says on the page “Any tag you like”:

Remember that OpenStreetMap does not have any content restrictions on tags that can be assigned to nodes, ways or areas. You can use any tags you like, but please document them here on the OpenStreetMap wiki, even if self-explanatory. Documenting allows others to find your features or even to correct mapping errors they encounter near you.

which encourages every user having invented a new tag to write a wiki page afterwards for it. It is also clearly said that a proposal process is not necessary to introduce a new tag (1st line of the above linked wiki page).

If this is not wanted and wiki pages should only be written after some kind of introduction of a new tag here in the forum or anywhere else then the expected process should also be clearly explained in the wiki to avoid misunderstandings.

[Jarek]

I would want to edit that page so that it specifies what the tag is supposed to mean and how it can be verified, but with less editorializing, and keep it in the main namespace per Map_HeRo

[Mateusz_Konieczny]

I would say that problem with this page is not that it exists, wiki pages about tags only used by one person are fine.

Though, if this page exists - editorializing should be removed, dubiousness of this tag should be described. For start, many drugs or supplements will are not viable without fillers or stabilizers and this metric is nearly useless.

So I would move that page on account of being really low quality.

Though from what I see from say Tag:street vendor=yes: Revision history - OpenStreetMap Wiki and Tag:amenity=traffic park: Revision history - OpenStreetMap Wiki and Tag:dual carriageway=yes: Revision history - OpenStreetMap Wiki I tried to not create ages while I was literally single user of them.

(I initially planned to add disclaimer how I created such pages but failed to find them)

---

so I support moving this page into userspace (and deleting redirect) but not supporting proposed general rule and not supporting mandatory proposal process

[Zkir (Urban Eye)]

It’s quite surprising that we have official tagging pages, and that a successful proposal is required to document tags in the main wiki namespace.

[woodpeck (Frederik Ramm)]

A successful proposal process is not required to document a tag that is in use. But in use means much more than “I thought of this tag yesterday and I’ve started using it”.

[Minh_Nguyen (Minh Nguyễn)]

This reminds me of a discussion we had a couple years ago, about when a tag is common enough to be “in use”:

Wiki Status of tags: proposed or in-use (for low-usage ATYL)?

This is about how we document tags on wiki.osm.org, particularly about Status field. I’ve noticed several times now at several unrelated tags that there seems to be disagreement about in use vs. proposed tags. I have hard time finding other instances now (of course), but last one was Key:bicycle:physical here. In that particular case (as opposed to other that I’ve seen) it was I who’ve documented it as in use, as my reading of that status was that it is correct one to be used, due to e.g.: S…

“Any tag you like” is a rite of passage for a mapper. It’s liberating, and also risky. Those of us who have coined many tags look back at our first coinages and somewhat regret them after all. We still learned something in the process.

Putting procedural red tape around ATYL could stifle the innovation we want as a community. Whenever it results in a bad tag, the community has an opportunity to criticize and reform it. If someone goes out of their way to document their idea, that gives us even more visibility into any problems and helps us communicate more clearly.

On the other hand, we do need to be vigilant against problematic tags being coined in this manner. If a bystander sees a tagging page that sounds authoritative, they may not have the experience to know that it’s unverifiable, or duplicates an older tag for no good reason, or is defined too narrowly for a particular region.

As long as the tag is being used nontrivially in the database, we probably should have an article on it, but we can mitigate any confusion by making the article more honest and balanced. In the meantime, templates such as {{Undocumented tag}} and {{Questioned}} can point to a quick talk page comment raising concern about the article.

If the article is bad enough that it would need to be rewritten entirely, then it would be appropriate to move it to the author’s user space as a last resort, as you’ve done. However, I wouldn’t go further in strictly requiring discussion before acknowledging any newly used tag. That would probably led to less documentation, not more discussion.

[ZeLonewolf (Brian M Sperlongano)]

@woodpeck

but it is not allowed to create official-looking tagging pages for any tags you like without a prior discussion.

False. OSM is a do-ocracy. If you invent a new tag, you document it. This has been a thing forever.

If someone creates and documents a tag that is stupid, we are free to bring it up and debate it.

It is far better for someone to document their made-up tags, than to quietly add them to the database. That way we can at least understand who added the tag and what they were thinking.

I can’t believe I’m having to explain this in 2026.

[SimonPoole]

I’m probably part of the issue here, the mapper in question has been trying to game the system at least a bit by adding their hobby horse tag to presets by piggy backing on other tags that could legitimately be considered missing, which, lets say, “slightly annoyed” me.

Adding a wiki page, while in itself a good thing, has consequences: it gives the tag a certain level of legitimacy and prior to the current iD release would have led to the tag being proposed to unsuspecting mappers. In any case adding “in use” at such a level of non-use is at least misleading.

I would note that I have strongly advocated for people documenting new values they are using for existing keys. Essentially if the overall tagging scheme is approved and there is a value missing (think of cusine as an example) there is no reason not to add and document additional values (as long as brain was turned on in the process).

The case in question has a bit of that, but given the user considers this an attribute that should attached to pharmacies and the like, it probably needs a discussion as clearly not just a “diet”.

[mueschel]

I have to agree with most here that this kind of tags should be allowed to have a “normal” wiki page - in the user namespace they are hard to find and can’t be automatically linked e.g. by osm.org or taginfo.

However, I suggest to have the definition of “in use” a bit more strict and define that e.g. they have to be in use for some time.
I think that none of the currently available options for tag status cover the case “I started to use this new tag, here’s what it means”, so I suggest to introduce a new “yellow” status “freshly introduced” (name to be discussed) for these cases. Transition from this status to any other should be subject to some consensus among several users.

---

Currently defined status tags:
approved · de facto · deprecated · discardable · imported · in use · obsolete · undefined · voting · proposed

[Minh_Nguyen (Minh Nguyễn)]

@SimonPoole

I’m probably part of the issue here, the mapper in question has been trying to game the system at least a bit by adding their hobby horse tag to presets by piggy backing on other tags that could legitimately be considered missing, which, lets say, “slightly annoyed” me.

I figured there might be a backstory like this, so thanks for clarifying. Fortunately, if we already know someone is going out on a limb, we can deal with them individually without a blanket policy prescription.

@SimonPoole

Adding a wiki page, while in itself a good thing, has consequences: it gives the tag a certain level of legitimacy and prior to the current iD release would have led the tag being proposed to unsuspecting mappers. In any case adding “in use” at such a level of non-use is at least misleading.

I would note that I have strongly advocated for people documenting new values they are using for existing keys. Essentially if the overall tagging scheme is approved and there is a value missing (think of cusine as an example) there is no reason not to add and document additional values (as long as brain was turned on in the process).

I assume you’re referring to this change from earlier this month, which affects the raw tag editor as well as any open-ended field. This closes the loophole you describe, though it also closes off a method by which some good tags have become established without the developers having to get involved.

Some tagging schemes benefit from standardizing even rare values. Fortunately, iD now generates a complete list of country codes for country=* and language codes for language:*=*. For less predictable tagging schemes, iD relies more heavily on id-tagging-schema and name-suggestion-index than before. Both projects consider usage but will also reject B.S. if they spot it.

If someone any-tag-you-likes a mundane value for an established scheme (e.g., cuisine=*, payment:*=*, network=*), the “Any tag you like” article could document the steps to get it into editors. Some mappers will need more handholding with GitHub.

[Mateusz_Konieczny]

@Minh_Nguyen

If someone any-tag-you-likes a mundane value for an established scheme (e.g., cuisine=*, payment:*=*, network=*),

for cuisine= I wanted to add more values, but there was demand to wait for 500 uses and no else expressed view that lower threshold should be accepted.

Currently I am actively looking for cuisines that crossed this threshold - ethiopian got added, once british gets added I will look for the next one and so on. popular unsupported values of major keys also lists some.
If someone see missing value that should be supported, feel free to open an a pull request.

For payment subtags - I am not actively looking for missing ones, mostly because it is harder to judge which values are legitimate. If anyone see any missing they can be added to iD presets by making change similar to this one

[SomeoneElse (Andy Townsend)]

@Mateusz_Konieczny

for cuisine= I wanted to add more values, but there was demand to wait for 500 uses and no else expressed view that lower threshold should be accepted.

I think that iD needs to think through the process a bit more. The presets are only suggestions - users can scroll down and add ATYL tags directly. However, it needs to be a conscious decision to do that.

Too many preset choices will result in accidental misclicks far beyond actual usage; too few and data will be lost.

However where do you draw the line between (to take a hypothetical example) caribbean, antiguan and barbudan? Not every valid value needs to be a preset.

[Kovoschiz]

It’s basically proposed , without a formal proposal. This can be seen from the lack of statuslink= icon.
But one can draft a Proposal: without RfC. I do that.
A worse problem is listing them together with other recognized attributes in the feature page. Those can’t be easily distinguished as an article can by default, with status= , and Taginfo.

[Mateusz_Konieczny]

@SomeoneElse

Too many preset choices will result in accidental misclicks far beyond actual usage; too few and data will be lost.

I think in case of cuisine= with the current interface and option count adding more values is unlikely to increase error rate.

And makes things easier for people using translated presets (if new values got translated).

It is possible that a smarter interface would be better (no ideas for one right now), but I do not see how adding more options makes missclicks more likely.

[SomeoneElse (Andy Townsend)]

@Mateusz_Konieczny

I think in case of cuisine= with the current interface and option count adding more values is unlikely to increase error rate.

How do we know? Is there any kind of iD “what people clicked and what they meant” testing?

[Minh_Nguyen (Minh Nguyễn)]

@SomeoneElse

Too many preset choices will result in accidental misclicks far beyond actual usage; too few and data will be lost.

However where do you draw the line between (to take a hypothetical example) caribbean, antiguan and barbudan? Not every valid value needs to be a preset.

What you’re describing would be a risk if someone were to pollute the dropdown menu for certain fields, such as access=*, where the set of options and their order is fixed in code. However, most fields start with taginfo’s ranking of values by usage, either because the set of valid values is quite large (cuisine=*) or because there’s no logical sort order (also cuisine=*). The entries in id-tagging-schema’s field definition allow these values to be translated into human language.

All that changed recently is that very rare values at the very bottom of the list have gone away. In some cases, these values had been easy to reach by typing something into the field, but misclicking is neither more nor less of a problem now than it was a month ago.

I am one of a handful of mappers who have used cuisine=okinawan,^[1] which I believe to be a reasonable tag. There just aren’t a ton of Okinawan restaurants in OSM yet. If id-tagging-schema were to add this tag, it would not cause mappers to accidentally tag cuisine=okinawan when they really meant cuisine=noodle or cuisine=persian, because the list isn’t sorted alphabetically. No one would accidentally choose it on their way to cuisine=japanese or cuisine=asian, because the list isn’t sorted by flavor profile either.

Despite the low risk, id-tagging-schema hasn’t reached this far down the barrel yet. Five hundred is nothing special, just an arbitrary threshold to make sure the project is covering the values that matter most, before getting into minutiae that will generally be more difficult for maintainers and translators to handle without subject matter expertise or local knowledge.

---

1. More specifically, cuisine=japanese;okinawan, but iD knows how to work with semicolons. ↩︎

[Mateusz_Konieczny]

@SomeoneElse

How do we know? Is there any kind of iD “what people clicked and what they meant” testing?

In this case “I think” is describing how I reached this conclusion.

And yes, I agree that proper research or even cursory research would be a stronger evidence.

I would like to have enough time to do UI/UX testing of iD and spot especially bad cases. Though I am not convinced that it is especially efficient right now, some known issues are identified already. And it would be better to fix those before looking for new ones.

(though if someone has pile of funding - I did small scale UX testing before, it was useful, I would be happy to do it again, this time for iD, and also implement fixes for worst issues)

----------‐-----

And for why I think that adding new preset values will not increase missclicks? The cuisine list is long enough that adding few more entries or even several additional entries does not change format how data is displayed, how user interacts with it, does not change that selected option is shown to user after they click on it.

In either case you get long dropdown with inline search.
Yes, maybe you may need to type more to filter entries or scroll a bit more. But I do not think that either increases missclick risk much.

What could be changed is finding more reasonable ordering - currently it is neither alphabetically nor grouped by cuisine themes nor ordered in any legible way.
If order starts making sense maybe on user scrolling though list looking for their entry risk of user being less frustrated and abandoning attempt to find fitting cuisine would be reduced.

And yes, if someone scrolls through list and looks for their value then adding more and more entries makes more likely they will give up. Maybe select random one out of spite, though I treat it as a low rusk. Though I expect that in such case user accidentally miss clicking because they failed to find what they looked for is vanishingly unlikely.

And adding missing ones helps here, as someone looking for those will actually find it.

Note that adding few missing values is balanced by altogether stopping to display rare ones that qualified on account of having wiki page.

[Minh_Nguyen (Minh Nguyễn)]

I wonder if this was just a misunderstanding because id-tagging-schema also has actual presets for some common cuisine values, besides the entries in the Cuisine field’s dropdown menu. A dedicated preset would be overkill for a newly coined cuisine value, but possibly reasonable for some independent tag. It all depends. It’s not like the project has a bot that automatically merges anything over a certain amount of usage, so I don’t know what the concern was anyways. You’re more judicious than that.

[SimonPoole]

@Minh_Nguyen

All that changed recently is that very rare values …

That’s sugar coating things a bit, because if a “very rare” value is staring you in the face or somewhere at the end of a very long list, depends on the number of “not so rare” values. I suspect if you go through the complaints about iD supporting novel tagging you will find that they stem more from the former.