On 25/08/19 15:02, Joseph Eisenberg wrote:
Getting back to the original example, phone=* was proposed first and
voted on in 1/2008 - see
https://wiki.openstreetmap.org/wiki/Proposed_features/Phone - the tag
was rejected. Some people at the time did not think that OSM should
contain phone numbers, others preferred something like contact:phone.
However, starting in mid-2008 the tag started to be used anyway.
I don't think there was every a proposal from contact:phone. It
started being used in mid-2009, but was never more popular than
phone=* (except for 2 months in 2008, after a small import or switch
of tags to contact:phone), according to
https://taghistory.raifer.tech.
Over the past 12 months (8-2018 to 8-2019), contact:phone=* has
increased by 50k from 260k to 310k, while phone=* increased by 200k,
from 1200k to 1400k. So phone=* is clearly preferred by about a 4 to 1
ratio, even though the original proposal was rejected.
This is a good example of the "problem": the smaller group of people
who votes on tags does not always pick tags to approve which the
general mapping community will use, and sometimes rejects tags which
later become the "de facto" standard.
This may well be an example of the OSM wiki guiding people to a tag in
preference to other more logical tags ...
Type 'phone' into the OSMwiki search box and you get redirected to the key
'phone=*'.
This gets preferential treatment to the key 'contact:phone=*'.
I think that having a wiki page on the key/tag you want to promote is essential
to getting the numbers up.
And further if that key/value is prominent in any OSMwiki search then the
better the chance of it gaining use.
The 'rejection' of other tags is not one of consideration but tldr.
Few mappers will take the time to read all the info on a tag that looks to suit
what they have to map.
So my take home message here is;
Make a wiki page!
Premote that wiki page.
Demote, denigrate other competing tags in anyway possible.
The above should see the wanted tag become 'more popular', 'more common', 'more
accepted' than the other tags.
Not saying that is what I have done, but that appears to be the way of things.
- Joseph
On 8/25/19, Valor Naram <valin...@gmx.net> wrote:
That's why I want to involve all user groups. Mappers, developers and local
communities.
Cheerio
Sören Reinecke alias Valor Naram
-------- Original Message --------
Subject: Re: [Tagging] Multiple tags for one purpose
From: marc marc
To: tagging@openstreetmap.org
CC:
Le 24.08.19 à 18:04, Valor Naram a écrit :
why we have two tags for one purpose sometimes?
many (almost all bad) reasons can explain it :
- one key exist, a new schema is born with a new tag for the same
feature/meaning, but the new schema never got a proposal or the proposal
never go into voting or the accepted proposal doesn't said enought "this
tag is depreced" (ex : phone <> contact:phone) or the new tag have some
issue and therefore some mapper want a new schema that solve everything
before dropping the first one (source:maxspeed <> maxspeed:type)
- some key have high usage and a part of the community is unwilling to
apply some lifecycle to tag, hoping that one day, "the invisible hand of
the community" (parody of the concept of the invisible hand in
economics) will solve the problem while we bury our heads in the sand
to deny the problem it creates (for ex building=cooling_tower <>
tower:type=cooling)
- 2 key exist, one use by one editor, other rejetected by this editor
but used by all-expet-one (ex : crossing=marked)
- 2 key exist but the exact meaning vary according to who used it.
at the end, the only usable meaning is the same for both key (ex :
landuse=forest <> natural=wood)
- only one tag exist at the begining but the but the key is in
contradiction with the meaning/logic of the key and therefore some
have created a more structured alternative. however this alternative
is rejected by the default rendering because the other key has
a more important use. it is the problem of the egg and the hen.
(ex: landuse=grass with have a clear meaning which is not a landuse)
- all those involved in this ml and/or in a voting agree that a key
should be depreciated, but someone thinks it would take hundreds of
voters when there are not hundreds of participants. so motivated people
go their way and the problem remains (see the discussion this summer...
I don't remember the tag concerned)
- some depreciated tags can't be converted automaticly because the tag
have 2 meanings (ex power=sub_station). not enough mapper review those.
- some proposal "hides" a depreciated tag into several other good stuff.
at the end the proposal got rejected or some disagree to use "the vote".
imho a "proposal to depreciate a tag" need to be as small as possible
therefore the default osm.org editor think it must take the lead to
decide what to depreciated and do a distributed automated edit.
sometimes it corresponds to the opinion of the community, sometimes not,
and in this case the community has lost control and the automated edit
is poorly documented and sometime wrong. it sometimes leads to edit wars
or an unpleasant discussions, it further cools down people who want to
make another depreciation of a tag, or it motivates them to do so via a
ticket for an editor since if the dev agrees, it will happen even if the
community is against.
possible solutions based on my limited experience :
- talk to choice the better tag between 2 need to be done at the global
level, arguments must be listened but ignore noice like "the wrong tag
is too important to change"
- making mecanical edit to migrate a depreciated/bad tag to its new
value works well at the local (coutry) level, the discussion take place
with the local community, without being polluted by "opponents in
principle". several of us do that kind of thing.
- probably we should make a "network" to share the proposals, this would
have a global impact perhaps enought to progress on some tags while
"opponents in principle" continue to have no solution to the problems
exposed.
- it is only when several local communities have agreed on the same
choice and the countries in question have accepted a mass edition that
it is possible to risk such a demand at the global level.
I only did 3 at the global level, 2 to fix a bug in an editor,
a third to migrate a marginal key.
in 2 of the 3 cases, I had requests for explanations after the fact
despite it was discussed wherever I thought it was necessary. I learned
that next time, we will have to discuss even more and be even more
square about where the discussion is taking place and about the
documentation (one was not sufficiently documented when it begging).
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
