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). I am well aware of the unpleasant tone of my message, but I have not found a way to describe facts objectively while pointing out the problems that have persisted for years. Regards, Marc _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
