<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,</p>
<p>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.<br>
<br>
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.</p>
<p>1) Normalization<br>
</p>
<p>Data consumers treat phone=* and contact:phone=* using the
following methods:<br>
<br>
When reading OSM data:<br>
1.A) They ignore contact:phone=* or phone=*<br>
1.B) They normalize phone=* to contact:phone=* or vice versa<br>
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<br>
<br>
When writing OSM data back to the OSM database (upstream):<br>
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.<br>
If they choose 1.B) then the software will upload phone=* or
contact:phone=* if the users changes the telephone number.<br>
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)<br>
<br>
2) Normalization to offer user friendly interfaces for non-techies
to edit e.g. for POI owners/operators/supervisors</p>
<p>An example of a good UX/UI (User Experience/User Interface)
Workflow.<br>
<br>
The owner of a shop clicks on their shop entry in the app. The
software then downloads the following data from OSM servers:<br>
<br>
name=Example Shop<br>
phone=01234<br>
contact:phone=567890<br>
amenity=shop<br>
shop=clothes<br>
website=<a class="moz-txt-link-freetext" href="https://example.com">https://example.com</a><br>
wheelchair=yes<br>
toilets=yes<br>
toilets:wheelchair=yes<br>
<br>
The software normalizes the data (we assume the developer chose
1.C) and decided to keep contact:phone=*)<br>
<br>
name=Example Shop<br>
contact:phone=567890;01234<br>
amenity=shop<br>
shop=clothes<br>
website=<a class="moz-txt-link-freetext" href="https://example.com">https://example.com</a><br>
wheelchair=yes<br>
toilets=yes<br>
toilets:wheelchair=yes</p>
<p><br>
</p>
<p>After that the software puts that data in the GUI in a nice form
using a template and nice labels:<br>
<br>
Name<br>
<u>Example Shop</u><br>
<u></u></p>
<p>Telephone Number<br>
<u>567890</u> <u>01234</u></p>
<p>POI Typ<br>
<u>Shop for clothes</u></p>
<p>Website Url<br>
<u><a class="moz-txt-link-freetext" href="https://example.com">https://example.com</a></u></p>
<p>Wheelchair accessible<br>
- [x] yes - [ ] no</p>
<p>POI has toilets<br>
- [x] yes - [ ] no</p>
<p>POI has wheelchair accessible toilets<br>
- [x] yes - [ ] no</p>
<p><br>
</p>
<p>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</p>
<p><br>
</p>
<p>Name<br>
<u>Example Shop</u><br>
</p>
<p>Telephone Number<br>
<u>567890</u></p>
<p>POI Typ<br>
<u>Shop for clothes</u></p>
<p>Website Url<br>
<u><a class="moz-txt-link-freetext" href="https://example.com">https://example.com</a></u></p>
<p>Wheelchair accessible<br>
- [x] yes - [ ] no</p>
<p>POI has toilets<br>
- [x] yes - [ ] no</p>
<p>POI has wheelchair accessible toilets<br>
- [x] yes - [ ] no</p>
<p><br>
</p>
<p>The user hits "submit", the software validates the input and
after successful validation (without errors) it converts the input
back to</p>
<p>name=Example Shop<br>
contact:phone=567890<br>
amenity=shop<br>
shop=clothes<br>
website=<a class="moz-txt-link-freetext" href="https://example.com">https://example.com</a><br>
wheelchair=yes<br>
toilets=yes<br>
toilets:wheelchair=yes</p>
<p>and uploads it to OpenStreetMap<br>
<br>
3) Note what the software has done<br>
<br>
1. It abstracted the key=value logic away and hides it under a
hopefully beautiful UI<br>
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.<br>
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</p>
<p>Telephone Number<br>
<u>567890</u></p>
<p>Telephone Number<u><br>
01234</u></p>
<p><u>)</u></p>
<p>4. Because of 1.C) it forgot about phone=* and uploaded the
updated tagging with only contact:phone=* instead of both keys.</p>
<p><br>
</p>
<p>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.<br>
<u></u></p>
</body>
</html>