[Tagging] Deprecating phone=* in favor of more ambiguity in the database

[mail at marcos-martinez.net]

Hi, 

OSM is full of alternative tagging schemes for (nearly) identical
objects. Data users have to live with them. 

 	* -> This is the kind of categorical statement I referred to
previously. Who said it has to be this way? Who said we can't make an
effort to effectively "clean" the database? Is this written somewhere
down? Has the community been consulted? It seems this is not the case.
My impression is that these statements are repeated over and over and
the vast majority of mappers just take it for granted. I don't believe
so until shown evidence.

Attempts to "clean" the database normally fail when the alternatives
have large usage numbers. And they often waste a lot of time. 

 	* -> This attitude reminds me of those who oppose measures against
climate change. You are not saying that "alternative tagging schemes"
may have an advantage, you just resign to the apparent fact that this is
how life is, chaotic and unjust and the problem is so huge, so better
get used to it and "live with it". In the meantime the snowball keeps
growing. People keep adding data with those competing schemes, which
makes cleaning up at a later point so much harder, and due to the ever
growing amount of details people are trying to add to each object over
time the situation will worsen. I feel like a spectator watching OSM hit
a wall in slow motion, probably not tomorrow or in the next few years
but if our aim is to keep expanding the number of editors and make
Openstreetmap THE standard map for everybody on the planet - that point
will come if we don't take at least a few basic measures.

Marcos 

Am 29.01.2022 10:38, schrieb Volker Schmidt:

> OSM is full of alternative tagging schemes for (nearly) identical objects. Data users have to live with them. Attempts to "clean" the database normally fail when the alternatives have large usage numbers. And they often waste a lot of time. 
> 
> On Fri, 28 Jan 2022, 22:35 Robin Burek, <robin.burek at gmx.de> wrote: 
> 
>> "Richard Fairhurst" richard at systemed.net - 28. Januar 2022 19:59
>>> It isn't a hot topic for "people". It's a hot topic for Soren. There is already a consensus within the wider OSM community that there's nothing wrong with the phone= tag, it's just that Soren refuses to accept any viewpoint other than his own.
>> 
>> That's where you're so wrong. It may not be the case here, but on other channels this issue is raised by all kinds of people. Maybe you're not aware of it, but it's possible. Not me and apparently not Sören.
>> It's also not about the obsessive preference for one scheme, but the resolution of the double use. Because that's the consensus I take most ehen, that the coexistence of phone=* and contact:phone=* suck. And it leads to problems.
>> And I've been following the trials and in the multiple approaches there's clearly been a bias towards the contact:* scheme rather than the pure phone=* (65% must have been at the last proposal). And that's why I support this attempt to finally resolve this contradiction. Because one could easily solve this problem and simply arrange for an either/or vote. Because at some point you have to decide which scheme should be preferred.
>> And yes, OSM may not have the beautiful data structure that you would have in a new project today. But two keys describing the same thing has nothing to do with beautiful or unbeautiful, but simply a mistake that should be cleaned up. Better yesterday than today. But here I only notice blockage instead of productivity.
>> 
>> _______________________________________________
>> Tagging mailing list
>> Tagging at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> 
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20220129/4ed15b71/attachment.htm>