Creating a new tag for an as-yet-unmapped feature (key) with variants (differing values): no harder than making a formal Proposal (some effort, not terribly difficult) and getting a super-majority to Approve. Do-able, “some effort,” not trivial, but not impossible, either. I’ll say “about right.” Because that’s what “we, as OSM” already say.
There is also the more “rogue” (not well-sanctioned, rather “under the radar,” maybe looked at by some or many as “disapproved” or “questionable…”) method of simply “any tag you like, and using it in the wild” (without the whole Proposal process). That has its problems, like lots of potential and actual misunderstanding (for lack of documentation), as well as frowns from a wider community (for lack of achieving consensus). You can do this, but it is rather unorthodox. Sometimes (perhaps even rarely) what ends up emerging from this are good features that “come in through a back door,” but not very often. OSM is a community built by consensus, not autocratically by a single clever person (or small groups of them). Maybe, to get certain things “rolling along” in OSM’ earlier days, this did happen more often than now, but we are a mature, worldwide project now. We listen to ourselves and have good process. Creating a new tag TO REPLACE an existing tag, where you end up (or attempt to) deprecating EXISTING tagging should indeed be a rather high bar of difficulty: we do not want "wholesale replacement” of existing tagging (to be easy). It is possible to replace existing tagging, but it is intentionally difficult to do this, especially without wide community approval as to why, how the new is better than the old, and how much pain (of eliminating an existing feature of OSM) this will cause, and that it is worth it to suffer this pain. If you think about it, and especially if you have “grown up with OSM as IT has grown up,” you see the merits in this. If not, it might seem odd, or nonsensical. Please understand that these are organic, evolving processes, and they “grow up,” too. We don’t want them to get brittle in their old age, we want them to be flexible enough to accommodate a real world that evolves in a database that must achieve SOME consistency. We want to “bend without breaking.” But we can also bend so much we snap and break, too. Once again (in this phase of Libra), I remind us that “balances can be struck,” and they should be. _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
