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

[Sören Reinecke]

Hi,

I want to deprecate phone=* in favor of more ambiguity in the OSM
database, providing more clarity for data cusomers to have just one key
with the same meaning.

I know that some of you told me already multiple times that phone=* and
contact:phone=* do NOT mean the same thing but this isn't true. Data
consumers treat phone=* and contact:phone=* the same no matter what you say.

1) Normalization

Data consumers treat phone=* and contact:phone=* using the following
methods:

When reading OSM data:
1.A) They ignore contact:phone=* or phone=*
1.B) They normalize phone=* to contact:phone=* or vice versa
1.C) They normalize phone=* to contact:phone=* or vice versa. If both
keys are set but with different values it will be normalized to
phone=phonenumberA;phonenumberB or
contact:phone=phone=phonenumberA;phonenumberB

When writing OSM data back to the OSM database (upstream):
If they choose 1.A) then the software only displays contact:phone=* or
phone=*, let's only edit & upload the change of one of them.
If they choose 1.B) then the software will upload phone=* or
contact:phone=* if the users changes the telephone number.
If they choose 1.C) then the users sees a semicolon separated list of at
least two phone numbers and does not know why there are two different
phone numbers. The latter is not that problematic since some POIs have
two or more telephone numbers in reality. It is just problematic if it
occurs because of 1.C)

2) Normalization to offer user friendly interfaces for non-techies to
edit e.g. for POI owners/operators/supervisors

An example of a good UX/UI (User Experience/User Interface) Workflow.

The owner of a shop clicks on their shop entry in the app. The software
then downloads the following data from OSM servers:

name=Example Shop
phone=01234
contact:phone=567890
amenity=shop
shop=clothes
website=https://example.com
wheelchair=yes
toilets=yes
toilets:wheelchair=yes

The software normalizes the data (we assume the developer chose 1.C) and
decided to keep contact:phone=*)

name=Example Shop
contact:phone=567890;01234
amenity=shop
shop=clothes
website=https://example.com
wheelchair=yes
toilets=yes
toilets:wheelchair=yes


After that the software puts that data in the GUI in a nice form using a
template and nice labels:

Name
_Example Shop_
__

Telephone Number
_567890_ _01234_

POI Typ
_Shop for clothes_

Website Url
_https://example.com_

Wheelchair accessible
- [x] yes      - [ ] no

POI has toilets
- [x] yes      - [ ] no

POI has wheelchair accessible toilets
- [x] yes      - [ ] no


We assume now that the user removes one of the telephone numbers because
it's outdated which gives us the following form at the end before submit


Name
_Example Shop_

Telephone Number
_567890_

POI Typ
_Shop for clothes_

Website Url
_https://example.com_

Wheelchair accessible
- [x] yes      - [ ] no

POI has toilets
- [x] yes      - [ ] no

POI has wheelchair accessible toilets
- [x] yes      - [ ] no


The user hits "submit", the software validates the input and after
successful validation (without errors) it converts the input back to

name=Example Shop
contact:phone=567890
amenity=shop
shop=clothes
website=https://example.com
wheelchair=yes
toilets=yes
toilets:wheelchair=yes

and uploads it to OpenStreetMap

3) Note what the software has done

1. It abstracted the key=value logic away and hides it under a hopefully
beautiful UI
2. It enabled the user to edit data without having to understand the
underlying tagging scheme and without the need to spend hours reading
across various wiki pages just to find what they need.
3. Because of 1.C) it merged phone=* into contact:phone=* (to prevent
conflicts and to be able to not show two form elements like

Telephone Number
_567890_

Telephone Number_
01234_

_)_

4. Because of 1.C) it forgot about phone=* and uploaded the updated
tagging with only contact:phone=* instead of both keys.


I hope it is now understandable why I am so arrogantly pushing you
towards my proposed solution(s) and not giving up doing so. It would be
great to see the voices of developers heard who develop using UNIX
philosophy (notably the KISS one) and or develop non-techy user oriented.
__
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20220126/ad4e9c32/attachment.htm>