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