[Tagging] Remove non-prefixed versions of 'contact:' scheme

[Paul Allen]

On Mon, 11 May 2020 at 01:38, Cj Malone <CjMalone at mail.com> wrote:

> On Sun, 2020-05-10 at 23:07 +0100, Paul Allen wrote:
> > > and gradually deprecating the generic tags.
> >
> > And there you go, wanting to get rid of phone=* and website=*.
>
> I think I stand by that quote, but I'm happy to discus it. I'm not
> arguing that over night we should stop people using the phone tag.
>

And yet you, and others, keep saying it.  "Deprecate" means "express
disapproval of."  In the context of OSM, it means "phase out."  That is,
eradicate with the passage of time.  It may not be what you mean, but
it's what you keep saying.

Currently phone has at least 2 uses. A contact number and an incoming
> number for a phone box. We should split these out. If we are left with
> totally_new_tag_for_phoneboxes and phone, where
> totally_new_tag_for_phoneboxes is defined as incoming phone number and
> phone is defined as the contact number. I'm OK with that too, it's the
> definitions that really matter.
>

Replacing tags isn't easy.  There is inertia from various parties involved.
Carto has a rule of "no aliases."  Which means that however compelling
you feel that replacing a=b with x=y is a good idea, they'll almost
certainly
reject it because "no aliases."  The editor people have their own foibles,
too,
but they're more likely to decide they don't like a=b or x=y and go with
p=q.

Oh, and there's all the legacy usage you have to clean up, except
we don't like automated edits.  But without cleaning it up, you make
database queries more complex.

As this conversation has gone on, I now believe that contact:phone and
> phone are separate things. As such I believe phone is massively misused
> as a contact number and so should actually be contact:phone. Lets
> gradually move people away from this.
>

I am far from convinced that a contact phone number is not a phone number.
If I see a phone=* on a phone box I know it is not a contact number.  If
I see a phone=* on a business I know it's a contact phone number for
the business.  What extra utility does having contact:phone provide?
And is it worth the hassle of manually editing all the existing tags to
fix?

>
> - We can start with documenting the differences between the tags on the
> Wiki.
>

I don't see any useful difference.  It's a phone number.  I dial it and the
phone on the other end rings.  Why would I expect a business to have
a phone number they never answer?

- Lets get the editors to push mappers use the accurate tag, is this a
> contact number, or another form of number.
>

What difference does it make?  I can understand wanting to distinguish
fax numbers from numbers that people answer.  That doesn't
require contact:phone=* for the voice number, just fax=* for the
fax number.

- And then lets start informing OSM maintainers about the ambiguous use
> of phone and give warnings to use a more quantified tag.
>

First you have to convince them that this is a good idea in the first place.
And you'll have to convince some people on the list that having a "more
quantified" tag is a good thing.

>
> The above 2 paragraphs might be easier to think of context of website
> and contact:website. I have previously misused them, I have been adding
> contact:website that are web pages for the specific store, but just
> have a contact number and address. That's not a contact method and so
> doesn't belong in contact:website.
>

I'm far from convinced that contact:website is useful.  It's certainly
semantically wrong.  It's a contact;webpage not a contact:website
(there are maybe a handful of exceptions to that).  Why do you think
the user is more likely to require the webpage giving contact details
rather than the home page of the web site?  I'd expect users are
more likely to want more information on what a POI is than to
want to find out how to contact it.

I find the whole contact: namespace to be ill-conceived.  But fine, if
you want it then use it.  Just please stop suggesting that we
deprecate website=* and phone=*.

-- 
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20200511/475e4b8e/attachment.htm>