Multiple tags for one purpose

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Multiple tags for one purpose

Valor Naram
Hey,

some long time ago I wondered why we have two tags for one purpose sometimes? For example: A mapper can use either the tag `contact:phone` or `phone` to add a phone number to the database. I think this makes the database dirty and for developers - like me - it's annoying to support two or more tags for one purpose.

We need a system to prevent or instinct the usage of two or more tags for one purpose. I suggest the following behaviour:
1. Negotiating which key can be considered as official.
1.1. A key which has been approved should be the official key but other factors like usage or improving can be considered.
2. Deprecating the other key by following the introductions on the https://wiki.openstreetmap.org/wiki/Deprecated_features page.
2.1. Opening issues for incorporating the official key into presets and removing presets with the old key:
2.1.6. ...
2.2. See how much the official key is used among mappers on https://taginfo.openstreetmap.org/ and also see the usage count for the old key. (For a period of 2-3 month)
2.2.1. If things are developing well and the official key gets more usage and the old key less usage then we won't need a mechanical edit.
2.2.2. If things aren't working for some reasons like there are not many real objects that can be tagged with the official key then we will do a mechanical edit but keeping the `check_date` and `review_requested` keys intact.

I also had an interesting talk with Quincy Morgan at https://github.com/openstreetmap/iD/issues/6529#issuecomment-524437983 about "fragmentation" as Morgan calls it.


In my opinion this is a topic we should consider working on and creating a wikipage to describe the "defragemtation" process in general.

Cheers,

Sören Reinecke alias Valor Naram

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Multiple tags for one purpose

Paul Allen


On Sat, 24 Aug 2019 at 17:06, Valor Naram <[hidden email]> wrote:

In my opinion this is a topic we should consider working on and creating a wikipage to describe the "defragemtation" process in general.

Doing so is probably not going to achieve much.  First we need to defragment OSM itself.
It doesn't matter what wonderful tags we come up with here, if carto refuses to render them
then they won't get used.  It doesn't matter what wonderful tags we come up with here, if editors
don't implement them as presets they won't get used.

Carto won't (in general) render a tag unless it's widely used.  Editors won't (in general)
implement tags in presets unless they're widely used.  Unless editors and carto support
tags, they won't get widely used, so editors and carto won't support them.  Chicken and egg.

There are complications (of course).  Carto (in general) refuses to implement aliases, so
whatever the merits of deprecating landuse=grass in favour of landcover=grass, carto will
refuse to render landcover=grass.  Editors don't (in general) like implementing aliases
either.  So however much we wish to try to fix bad tags, which are frequently misused
because the name or value was a bad choice, it probably won't happen.  Some editors
occasionally decide they'll ignore the list, the wiki, and carto, and go their own way
(sometimes they get their way and sometimes they get a slap on the wrist).

So what we need at this stage is not a defragmentation process but joined-up thinking
between the various groups.  I'm not holding my breath on that one.

--
Paul


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Multiple tags for one purpose

Peter Elderson
In reply to this post by Valor Naram
Valor Naram <[hidden email]> het volgende geschreven:

We need a system to prevent or instinct the usage of two or more tags for one purpose. I suggest the following behaviour:
1. Negotiating which key can be considered as official.

Who will negotiate, what do they have to negiate with?
What office makes it official? What process?

Chances are you will never get consensus. 

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Multiple tags for one purpose

Tagging mailing list
The tagging Community (this list) will negotiate it and it's the office at the same time. The process should be like the process for proposals but only discussion and vote.

Regards

Sören Reinecke alias Valor Naram


-------- Original Message --------
Subject: Re: [Tagging] Multiple tags for one purpose
From: Peter Elderson
To: "Tag discussion, strategy and related tools"
CC:


Valor Naram <[hidden email]> het volgende geschreven:

We need a system to prevent or instinct the usage of two or more tags for one purpose. I suggest the following behaviour:
1. Negotiating which key can be considered as official.

Who will negotiate, what do they have to negiate with?
What office makes it official? What process?

Chances are you will never get consensus. 

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Multiple tags for one purpose

Valor Naram
In reply to this post by Paul Allen
> Editors won't (in general) implement tags in presets unless they're widely used.  Unless editors and carto support tags, they won't get widely used, so editors and carto won't support them.  Chicken and egg.

Yes, you're right. But I was the author of "changing_table" and the guy who lead it throw the proposal process and also Moderator of the discussion and votes. And contacting all the editors was no problem and they implemented "changing_table" and deleted "diaper" presets. See JSOM, OSMand, Vespucci and also iD. My effort shows that working together with different groups works.

I would highly appreciate it when you give me a chance. In real life people are revelling their secrets to me because they trust me and I give them the feeling of being accepted as they are. It includes my talks with people from different worlds. More-Than-One-World Secrets. This connection I can try to create also among OSM folks (societies).

Best regards

Sören Reinecke alias Valor Naram


-------- Original Message --------
Subject: Re: [Tagging] Multiple tags for one purpose
From: Paul Allen
To: "Tag discussion, strategy and related tools"
CC:




On Sat, 24 Aug 2019 at 17:06, Valor Naram <[hidden email]> wrote:

In my opinion this is a topic we should consider working on and creating a wikipage to describe the "defragemtation" process in general.

Doing so is probably not going to achieve much.  First we need to defragment OSM itself.
It doesn't matter what wonderful tags we come up with here, if carto refuses to render them
then they won't get used.  It doesn't matter what wonderful tags we come up with here, if editors
don't implement them as presets they won't get used.

Carto won't (in general) render a tag unless it's widely used.  Editors won't (in general)
implement tags in presets unless they're widely used.  Unless editors and carto support
tags, they won't get widely used, so editors and carto won't support them.  Chicken and egg.

There are complications (of course).  Carto (in general) refuses to implement aliases, so
whatever the merits of deprecating landuse=grass in favour of landcover=grass, carto will
refuse to render landcover=grass.  Editors don't (in general) like implementing aliases
either.  So however much we wish to try to fix bad tags, which are frequently misused
because the name or value was a bad choice, it probably won't happen.  Some editors
occasionally decide they'll ignore the list, the wiki, and carto, and go their own way
(sometimes they get their way and sometimes they get a slap on the wrist).

So what we need at this stage is not a defragmentation process but joined-up thinking
between the various groups.  I'm not holding my breath on that one.

--
Paul


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Multiple tags for one purpose

marc marc
In reply to this post by Valor Naram
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Multiple tags for one purpose

Mateusz Konieczny-3
In reply to this post by Paul Allen

24 Aug 2019, 18:39 by [hidden email]:
Editors won't (in general)
implement tags in presets unless they're widely used. 
This is not true. Barrier for support in editors
is really low.

Many tags that are not widely used are
supported.

For example man_made=obelisk 
support was just added to iD,
based on my simple issue requesting it.
(it is so recent that version with is probably currently not deployed)

JOSM developers respond well to
requests to support sensible tags.

Popular tags are not even requiring that -
JOSM developers actively monitor popular unsupported tags.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Multiple tags for one purpose

Valor Naram
In reply to this post by marc marc
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: [hidden email]
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).

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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Multiple tags for one purpose

Joseph Eisenberg
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.

- Joseph

On 8/25/19, Valor Naram <[hidden email]> 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: [hidden email]
> 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).
>>
>> 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
>> [hidden email]
>> https://lists.openstreetmap.org/listinfo/tagging
>

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Multiple tags for one purpose

Warin
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 <[hidden email]> 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: [hidden email]
>> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Multiple tags for one purpose

Valor Naram
In reply to this post by Joseph Eisenberg
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.

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.

Best regards

Sören Reinecke alias Valor Naram


-------- Original Message --------
Subject: Re: [Tagging] Multiple tags for one purpose
From: Joseph Eisenberg
To: "Tag discussion, strategy and related tools"
CC:


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.

- Joseph

On 8/25/19, Valor Naram 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: [hidden email]
> 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).
>>
>> 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
>> [hidden email]
>> https://lists.openstreetmap.org/listinfo/tagging
>

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

phone vs contact:phone WAS Re: Multiple tags for one purpose

dieterdreist
In reply to this post by Warin


sent from a phone

> On 25. Aug 2019, at 07:20, Warin <[hidden email]> wrote:
>
> Type 'phone' into the OSMwiki search box and you get redirected to the key 'phone=*'.
> This gets preferential treatment to the key 'contact:phone=*'.


seems fair that “key:phone” shows up first for a search for “phone”, it’s straightforward, and it’s also the most used tag for phone (numbers).

The contact prefix is pointless, why would we make everybody who doesn’t use presets type longer key names when there are no alternatives which would require to distinguish the tag from? People who do use presets don’t have to care for tag names anyway.

If you search for “contact phone” the first hit is key:contact, one could argue a better result would be showing key:phone first for this search term as well, as it is the mostly used tag for a generic phone number.

What about deprecating the contact: prefix, at least for phone? It doesn’t seem it will ever make it and is basically a deliberate tag fragmentation.

Cheers Martin
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: phone vs contact:phone WAS Re: Multiple tags for one purpose

Valor Naram
> What about deprecating the contact: prefix, at least for phone? It doesn’t seem it will ever make it and is basically a deliberate tag fragmentation.

Yes, I recommend deprecating `contact:phone`


-------- Original Message --------
Subject: [Tagging] phone vs contact:phone WAS Re: Multiple tags for one purpose
From: Martin Koppenhoefer
To: "Tag discussion, strategy and related tools"
CC:




sent from a phone

> On 25. Aug 2019, at 07:20, Warin <[hidden email]> wrote:
>
> Type 'phone' into the OSMwiki search box and you get redirected to the key 'phone=*'.
> This gets preferential treatment to the key 'contact:phone=*'.


seems fair that “key:phone” shows up first for a search for “phone”, it’s straightforward, and it’s also the most used tag for phone (numbers).

The contact prefix is pointless, why would we make everybody who doesn’t use presets type longer key names when there are no alternatives which would require to distinguish the tag from? People who do use presets don’t have to care for tag names anyway.

If you search for “contact phone” the first hit is key:contact, one could argue a better result would be showing key:phone first for this search term as well, as it is the mostly used tag for a generic phone number.

What about deprecating the contact: prefix, at least for phone? It doesn’t seem it will ever make it and is basically a deliberate tag fragmentation.

Cheers Martin
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: phone vs contact:phone WAS Re: Multiple tags for one purpose

Colin Smale

Your model (using only phone=*) only allows an object to have a single phone number. How do you propose modelling multiple phone numbers on a single object? For example, one for general enquiries, one for emergencies, one for staff,...

Note I am not talking about tagging here, but trying to discuss the underlying data model.

 


On 2019-08-25 17:11, Valor Naram wrote:

> What about deprecating the contact: prefix, at least for phone? It doesn't seem it will ever make it and is basically a deliberate tag fragmentation.

Yes, I recommend deprecating `contact:phone`



-------- Original Message --------
Subject: [Tagging] phone vs contact:phone WAS Re: Multiple tags for one purpose
From: Martin Koppenhoefer
To: "Tag discussion, strategy and related tools"
CC:




sent from a phone

> On 25. Aug 2019, at 07:20, Warin wrote:
>
> Type 'phone' into the OSMwiki search box and you get redirected to the key 'phone=*'.
> This gets preferential treatment to the key 'contact:phone=*'.


seems fair that "key:phone" shows up first for a search for "phone", it's straightforward, and it's also the most used tag for phone (numbers).

The contact prefix is pointless, why would we make everybody who doesn't use presets type longer key names when there are no alternatives which would require to distinguish the tag from? People who do use presets don't have to care for tag names anyway.

If you search for "contact phone" the first hit is key:contact, one could argue a better result would be showing key:phone first for this search term as well, as it is the mostly used tag for a generic phone number.

What about deprecating the contact: prefix, at least for phone? It doesn't seem it will ever make it and is basically a deliberate tag fragmentation.

Cheers Martin
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Multiple tags for one purpose

SimonPoole
In reply to this post by Valor Naram


Am 24.08.2019 um 21:03 schrieb Valor Naram:
> Editors won't (in general) implement tags in presets unless they're widely used.  Unless editors and carto support tags, they won't get widely used, so editors and carto won't support them.  Chicken and egg.

Yes, you're right. But I was the author of "changing_table" and the guy who lead it throw the proposal process and also Moderator of the discussion and votes. And contacting all the editors was no problem and they implemented "changing_table" and deleted "diaper" presets. See JSOM, OSMand, Vespucci and also iD. My effort shows that working together with different groups works.

A) at least I didn't "delete" the diaper preset.

B) you are confusing the decision that something is too silly to argue about, with agreement.


I would highly appreciate it when you give me a chance. In real life people are revelling their secrets to me because they trust me and I give them the feeling of being accepted as they are. It includes my talks with people from different worlds. More-Than-One-World Secrets. This connection I can try to create also among OSM folks (societies).

That is seriously OT.


Best regards

Sören Reinecke alias Valor Naram


-------- Original Message --------
Subject: Re: [Tagging] Multiple tags for one purpose
From: Paul Allen
To: "Tag discussion, strategy and related tools"
CC:




On Sat, 24 Aug 2019 at 17:06, Valor Naram <[hidden email]> wrote:

In my opinion this is a topic we should consider working on and creating a wikipage to describe the "defragemtation" process in general.

Doing so is probably not going to achieve much.  First we need to defragment OSM itself.
It doesn't matter what wonderful tags we come up with here, if carto refuses to render them
then they won't get used.  It doesn't matter what wonderful tags we come up with here, if editors
don't implement them as presets they won't get used.

Carto won't (in general) render a tag unless it's widely used.  Editors won't (in general)
implement tags in presets unless they're widely used.  Unless editors and carto support
tags, they won't get widely used, so editors and carto won't support them.  Chicken and egg.

There are complications (of course).  Carto (in general) refuses to implement aliases, so
whatever the merits of deprecating landuse=grass in favour of landcover=grass, carto will
refuse to render landcover=grass.  Editors don't (in general) like implementing aliases
either.  So however much we wish to try to fix bad tags, which are frequently misused
because the name or value was a bad choice, it probably won't happen.  Some editors
occasionally decide they'll ignore the list, the wiki, and carto, and go their own way
(sometimes they get their way and sometimes they get a slap on the wrist).

So what we need at this stage is not a defragmentation process but joined-up thinking
between the various groups.  I'm not holding my breath on that one.

--
Paul


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: phone vs contact:phone WAS Re: Multiple tags for one purpose

Paul Allen
In reply to this post by Colin Smale
On Sun, 25 Aug 2019 at 16:46, Colin Smale <[hidden email]> wrote:

Your model (using only phone=*) only allows an object to have a single phone number. How do you propose modelling multiple phone numbers on a single object? For example, one for general enquiries, one for emergencies, one for staff,...


I've seen this on car dealerships.  One number for the Hyundai franchise, another for the VW
franchise, another for repairs and a repeat of one of the franchise numbers for general
enquiries.  Some larger businesses have several numbers for different purposes rather
than having everything go through a single number.

--
Paul


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: phone vs contact:phone WAS Re: Multiple tags for one purpose

Andy Mabbett
In reply to this post by Colin Smale
On Sun, 25 Aug 2019 at 16:42, Colin Smale <[hidden email]> wrote:
>
> Your model (using only phone=*) only allows an object to have a single phone number. How do you propose modelling multiple phone numbers on a single object? For example, one for general enquiries, one for emergencies, one for staff,...

there are at least two possibilities:


phone=
phone:emergency=
phone:staff=

and:

phone=
emergency:phone=
staff:phone=

Neither of which requires "contact:"

--
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Multiple tags for one purpose

yo paseopor
In reply to this post by Valor Naram
This not always works.

See traffic_sign:direction=* and traffic_signal:direction=* or crossing=marked  in iD or all the "missions" you will not see implemented in StreetComplete and the impossibility of make it more scalable and customizable.

One person said here to a question about a reasonible good proposal of new tagging for schools and other educative centers:

"Ask any two people on this list their opinion on any matter and you will get THREE opinions."

Good luck with it.
yopaseopor


On Sat, Aug 24, 2019 at 9:05 PM Valor Naram <[hidden email]> wrote:
> Editors won't (in general) implement tags in presets unless they're widely used.  Unless editors and carto support tags, they won't get widely used, so editors and carto won't support them.  Chicken and egg.

Yes, you're right. But I was the author of "changing_table" and the guy who lead it throw the proposal process and also Moderator of the discussion and votes. And contacting all the editors was no problem and they implemented "changing_table" and deleted "diaper" presets. See JSOM, OSMand, Vespucci and also iD. My effort shows that working together with different groups works.

I would highly appreciate it when you give me a chance. In real life people are revelling their secrets to me because they trust me and I give them the feeling of being accepted as they are. It includes my talks with people from different worlds. More-Than-One-World Secrets. This connection I can try to create also among OSM folks (societies).

Best regards

Sören Reinecke alias Valor Naram


-------- Original Message --------
Subject: Re: [Tagging] Multiple tags for one purpose
From: Paul Allen
To: "Tag discussion, strategy and related tools"
CC:




On Sat, 24 Aug 2019 at 17:06, Valor Naram <[hidden email]> wrote:

In my opinion this is a topic we should consider working on and creating a wikipage to describe the "defragemtation" process in general.

Doing so is probably not going to achieve much.  First we need to defragment OSM itself.
It doesn't matter what wonderful tags we come up with here, if carto refuses to render them
then they won't get used.  It doesn't matter what wonderful tags we come up with here, if editors
don't implement them as presets they won't get used.

Carto won't (in general) render a tag unless it's widely used.  Editors won't (in general)
implement tags in presets unless they're widely used.  Unless editors and carto support
tags, they won't get widely used, so editors and carto won't support them.  Chicken and egg.

There are complications (of course).  Carto (in general) refuses to implement aliases, so
whatever the merits of deprecating landuse=grass in favour of landcover=grass, carto will
refuse to render landcover=grass.  Editors don't (in general) like implementing aliases
either.  So however much we wish to try to fix bad tags, which are frequently misused
because the name or value was a bad choice, it probably won't happen.  Some editors
occasionally decide they'll ignore the list, the wiki, and carto, and go their own way
(sometimes they get their way and sometimes they get a slap on the wrist).

So what we need at this stage is not a defragmentation process but joined-up thinking
between the various groups.  I'm not holding my breath on that one.

--
Paul

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: phone vs contact:phone WAS Re: Multiple tags for one purpose

Valor Naram
In reply to this post by Colin Smale
https://wiki.openstreetmap.org/wiki/Key:phone and https://wiki.openstreetmap.org/wiki/Key:contact don't provide any tagging method to tag numbers for emergency, general enquiries etc. Both keys just allow the tagging of one phone number on one object.

But feel free to write a proposal to extend the tagging scheme of `phone` to:
- `phone`
- `phone:emergency`
- `phone:night`
- `phone:press`

Feel free also to extend the `email` tag:
- `email`
- `email:press`
- `email:legal`

But we're drifting away from the topic "Multiple tags for one purpose". We should discuss the problem of "fragmentation" in general. But deprecating `contact:phone` in favor of `phone` can be the logical step.

Cheers

Sören Reinecke alias Valor Naram


-------- Original Message --------
Subject: Re: [Tagging] phone vs contact:phone WAS Re: Multiple tags for one purpose
From: Colin Smale
To: [hidden email]
CC:


Your model (using only phone=*) only allows an object to have a single phone number. How do you propose modelling multiple phone numbers on a single object? For example, one for general enquiries, one for emergencies, one for staff,...

Note I am not talking about tagging here, but trying to discuss the underlying data model.

 


On 2019-08-25 17:11, Valor Naram wrote:

> What about deprecating the contact: prefix, at least for phone? It doesn't seem it will ever make it and is basically a deliberate tag fragmentation.

Yes, I recommend deprecating `contact:phone`



-------- Original Message --------
Subject: [Tagging] phone vs contact:phone WAS Re: Multiple tags for one purpose
From: Martin Koppenhoefer
To: "Tag discussion, strategy and related tools"
CC:




sent from a phone

> On 25. Aug 2019, at 07:20, Warin wrote:
>
> Type 'phone' into the OSMwiki search box and you get redirected to the key 'phone=*'.
> This gets preferential treatment to the key 'contact:phone=*'.


seems fair that "key:phone" shows up first for a search for "phone", it's straightforward, and it's also the most used tag for phone (numbers).

The contact prefix is pointless, why would we make everybody who doesn't use presets type longer key names when there are no alternatives which would require to distinguish the tag from? People who do use presets don't have to care for tag names anyway.

If you search for "contact phone" the first hit is key:contact, one could argue a better result would be showing key:phone first for this search term as well, as it is the mostly used tag for a generic phone number.

What about deprecating the contact: prefix, at least for phone? It doesn't seem it will ever make it and is basically a deliberate tag fragmentation.

Cheers Martin
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: phone vs contact:phone WAS Re: Multiple tags for one purpose

Andrew Hain
Unless you can justify a difference based on the nature of the information recorded instead of tag counts, deprecating contact:phone makes tagging less orthogonal, which is a nuisance for both mappers and map consumers.

--
Andrew

From: Valor Naram <[hidden email]>
Sent: 25 August 2019 17:40
To: Tag discussion, strategy and related tools <[hidden email]>
Subject: Re: [Tagging] phone vs contact:phone WAS Re: Multiple tags for one purpose
 
https://wiki.openstreetmap.org/wiki/Key:phone and https://wiki.openstreetmap.org/wiki/Key:contact don't provide any tagging method to tag numbers for emergency, general enquiries etc. Both keys just allow the tagging of one phone number on one object.

But feel free to write a proposal to extend the tagging scheme of `phone` to:
- `phone`
- `phone:emergency`
- `phone:night`
- `phone:press`

Feel free also to extend the `email` tag:
- `email`
- `email:press`
- `email:legal`

But we're drifting away from the topic "Multiple tags for one purpose". We should discuss the problem of "fragmentation" in general. But deprecating `contact:phone` in favor of `phone` can be the logical step.

Cheers

Sören Reinecke alias Valor Naram


-------- Original Message --------
Subject: Re: [Tagging] phone vs contact:phone WAS Re: Multiple tags for one purpose
From: Colin Smale
To: [hidden email]
CC:


Your model (using only phone=*) only allows an object to have a single phone number. How do you propose modelling multiple phone numbers on a single object? For example, one for general enquiries, one for emergencies, one for staff,...

Note I am not talking about tagging here, but trying to discuss the underlying data model.

 


On 2019-08-25 17:11, Valor Naram wrote:

> What about deprecating the contact: prefix, at least for phone? It doesn't seem it will ever make it and is basically a deliberate tag fragmentation.

Yes, I recommend deprecating `contact:phone`



-------- Original Message --------
Subject: [Tagging] phone vs contact:phone WAS Re: Multiple tags for one purpose
From: Martin Koppenhoefer
To: "Tag discussion, strategy and related tools"
CC:




sent from a phone

> On 25. Aug 2019, at 07:20, Warin wrote:
>
> Type 'phone' into the OSMwiki search box and you get redirected to the key 'phone=*'.
> This gets preferential treatment to the key 'contact:phone=*'.


seems fair that "key:phone" shows up first for a search for "phone", it's straightforward, and it's also the most used tag for phone (numbers).

The contact prefix is pointless, why would we make everybody who doesn't use presets type longer key names when there are no alternatives which would require to distinguish the tag from? People who do use presets don't have to care for tag names anyway.

If you search for "contact phone" the first hit is key:contact, one could argue a better result would be showing key:phone first for this search term as well, as it is the mostly used tag for a generic phone number.

What about deprecating the contact: prefix, at least for phone? It doesn't seem it will ever make it and is basically a deliberate tag fragmentation.

Cheers Martin
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
12