[Tagging] simply documenting tags WAS Re: hydrants
bkil.hu+Aq at gmail.com
Wed Oct 10 16:25:01 UTC 2018
I agree that similar to Wikipedia, we shouldn't put random, incorrect
or misleading stuff in the main namespace of the OSM wiki.
However, I view it as a harsh restriction to only allow documenting of
established tags the the main namespace. The main tag wiki pages are
cross linked from taginfo.
In the wiki pages I edit, I usually put less common attributes in
separate sections with extra warnings to avoid mistakes. Also, if you
create respective subpages of each property with the standard template
containing taginfo statistics and status enum, it becomes obvious how
established each property is.
We should of course have a clear and friendly process of handling
clashes - so it should not happen that two users would like to
advocate their two incompatible tagging scheme on the same page,
leading to edit wars. Two separate proposals need to be opened in this
case with strong-consensus voting for both. (However, in the case of
hydrant opening direction for example, I've checked beforehand and
validated that no applicable alternative scheme or proposal exists
other than the one noted and mention on a Hungarian page some years
The problem of (complicated) proposal pages is that they "rot" easily.
RFC and voting sometimes seems to be stuck. Some downvoted proposals
start to be taken up by mappers some years later (with an unfixed,
partially buggy/broken schema). Surely the correct life cycle of a
proposal should be that if it is dismissed, the proposer should
immediately clone the wiki page, increment a version number, correct
the problems highlighted by the voters and resubmit for RFC/voting.
Unfortunately, most of the volunteers seem to be overwhelmed by this
process and give up usually after the first attempt.
I sometimes take up the task of documenting random established, almost
established or emerging things I encounter in taginfo that I deem
useful for the community (or me). Why should I put these under my own
namespace? It would leave the impression that I "want" to do something
with the outlined tagging or that I want to "own" the tag. However, in
most of these cases, I simply want to be done with it and move on to
another tag or just be mapping instead of submitting proposals for
others. I did submit one (two) recently just to get the hang of it,
but I feel already that it takes up a lot of energy for little
"return". I feel that if I document trending clear-cut tags according
to my best knowledge, someone else can take up from there and improve
it (submit for RFC/Proposal).
This should be the ideal mechanism of the wisdom of the crowds - no
single person should bear an unreasonable burden, unless of course
that person finds enjoyment in this.
Of course this is only my personal view on the issue without much
context - I'm open for other points of view if others would like to
On Wed, Oct 10, 2018 at 9:39 AM Martin Koppenhoefer
<dieterdreist at gmail.com> wrote:
> sent from a phone
> On 10. Oct 2018, at 08:07, bkil <bkil.hu+Aq at gmail.com> wrote:
> I believe this paragraph needs some clarification, currently it reads “When you use tags yourself that aren't on map features, give other mappers a chance to understand (and maybe adopt) them by documenting them in the wiki.”
> Yes, it is a good thing to document custom tags, but the question is where in the wiki should you put a tag that is not (yet) established.
> Some tags work better than others, sometimes there are already alternative tagging methods established (and you might not be aware of it), simply adding a feature page for a tag which isn’t generally used, wasn’t discussed with the community and may be problematic is not a good idea.
> People also document tags on their user pages, and this is much better as the things are still searchable but there isn’t the risk of mistaking them for well established tags. Another way to make this clear is setting up a proposal page for documentation. A lot of tags have become established simply because there was a proposal and people were adopting it in their mapping (no formal voting).
> Map feature pages are for the documentation of established tags, I hope we can agree on this?
> IMHO we should clarify that documenting ad hoc tags in the wiki (link above) means either putting this documentation in your user space of the wiki, or in the proposal space.
> What do you think?
> Tagging mailing list
> Tagging at openstreetmap.org
More information about the Tagging