<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#333399" bgcolor="#FFFFFF">
<p><font face="Verdana">We had a similar situation some years ago
and solved it very successfully with overwhelming community
support. It is similar, allow me to describe the problem and how
we solved it:</font></p>
<p><font face="Verdana">Here in Africa we use Mobile Money services,
which are wallets on your phone provided by the private Telecom
Companies. The services are regulated by the government.
Besides using your wallet from your phone, the Telecom companies
started to grant money collection and depositing services
through banks, post offices and many private shops and kiosks.
Telecom Operators provide the same collection and deposit
service through their service centres, which you mostly find
only in the major towns. SO there was a big need to map all
those shops, banks, post offices, supermarkets etc... as Mobile
Money service providers.<br>
An existing tag existed: bureau_de_change, describing perfectly
the service provided. We didn't want to change all the other
amenity or top level keys, as they are not incorrect, and we
didn't want to introduce multiple values in one key. SO we
decided to follow the OSM guideline "one feature, one tag".
Created new nodes, next to all these other nodes and provided
all the necessary details, brand , operator, owner, contacts
etc..., all using existing tags, there was no need to introduce
subkeys etc... just some specific values used in this context.<br>
This led to many nodes with duplicate names (name of the shop or
supermarket is same as the name of the bureau_de_change service
provider. We solved that problem not consistently but the
options you have are:</font></p>
<p><font face="Verdana">- tag a building as amenity shop,
supermarket, bank, postal office etc..., and tag it with it's
primary service keys. Apply one unique name. In the building
add additional names for the supplementary services you want to
map, without providing a name. <br>
</font></p>
<p><font face="Verdana">- provide different nodes for different
services or products provided. Can be located in a building as
such, tagged with a unique name, or several different nodes,
they can all have a different operator and a different service.
You can use a group relation if you wish to connect them
together if you want to use just a single name (no duplicate
data).<br>
This one also solved the problem that in some cases the same
service was provided for different brands (telecom operators in
our case) at the same place. You could use different values in
brand separated by ; but different nodes for every service is
better, because it is not said that this particular place
delivers service A and B for brand 1, but maybe only service A
for brand 2.</font></p>
<p><font face="Verdana">Reflecting this back to your proposal you
could use the same principals with a minimum of specific service
keys in your cases. Using office=courier or office=logistics,
add brand, operator etc... all to a new node. Map them in the
same building if they operate under a common name or create a
group relation to define the common keys.</font></p>
<p><font face="Verdana">How does that sound ?</font></p>
<p><font face="Verdana">Greetings, Bert Araali<br>
</font></p>
<p><br>
</p>
<div class="moz-cite-prefix">On 16/02/2021 18:10, Robin Burek wrote:<br>
</div>
<blockquote type="cite"
cite="mid:b4c94fbe-a2f5-b594-6ad0-efffea7b052a@gmx.de">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">Am 16.02.2021 um 15:32 schrieb Bert
-Araali- Van Opstal:<br>
</div>
<blockquote type="cite"
cite="mid:886f0527-6488-b9e0-5812-bb680835cd86@gmail.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<font face="Verdana">My analysis:</font>
<p><font face="Verdana">If we refer to wikipedia (<a
class="moz-txt-link-freetext"
href="https://en.wikipedia.org/wiki/Post_office"
moz-do-not-send="true">https://en.wikipedia.org/wiki/Post_office</a>)
the term post office, postal service refers "</font> to
government postal facilities providing customer service." in
most parts of the world. And luckily wikipedia refers to the
German situation: "Private <a
href="https://en.wikipedia.org/wiki/Courier" title="Courier"
moz-do-not-send="true">courier</a> and <a
href="https://en.wikipedia.org/wiki/Package_delivery"
title="Package delivery" moz-do-not-send="true">delivery
services</a> often have offices as well, although these are
not usually called "post offices," except in the case of <a
href="https://en.wikipedia.org/wiki/Germany" title="Germany"
moz-do-not-send="true">Germany</a>, which has <a
href="https://en.wikipedia.org/wiki/Deutsche_Post"
title="Deutsche Post" moz-do-not-send="true">fully
privatized its national postal system</a>."</p>
</blockquote>
<p>Thats actually only discribe the position of "Deutsche Post"
(refered throw the link) but not the other private postal
service providers. (And it need to citation btw). <br>
<span class="VIiyi" lang="en"><span class="JLqJ4b ChMk0b"
data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="0"><span>I
refer again to the previously quoted Wikipedia entry
"mail":</span></span></span> "The mail or post is a
system for physically transporting postcards, letters, and
parcels." - <span class="VIiyi" lang="en"><span class="JLqJ4b
ChMk0b" data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="0"><span>Just
because there are many private providers and no state
postal service in Germany, these are still postal
services.</span></span> <span class="JLqJ4b ChMk0b"
data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="1"><span>And
wikipedia clearly includes parcels here.</span></span></span>
<br>
<span class="VIiyi" lang="en"><span class="JLqJ4b ChMk0b"
data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="0"><span></span></span></span>
</p>
<blockquote type="cite"
cite="mid:886f0527-6488-b9e0-5812-bb680835cd86@gmail.com">
<p>I'd like to propose the following to get this discussion
going again and proceed with the proposal since it looks fine
and clearly defines a need in the community:</p>
<p>Do not introduce a new key but use the existing
office=courier or office=logistics (I know, not widely used
but .. better then to introduce a new one which is not used so
far). Attribute those with keys to describe the services
offered, which might use post or postal terms in the values
but do not define them as a post or postal office, much as is
somehow clearly described on the English Wikipedia for the
German situation.</p>
</blockquote>
<p>In that opinion I should map the supermarket where I can buy
stamps, send mail and send parcels for "biber post" on the
normal cashier-desk with amenity=post_office, office=courier and
shop=supermarket? Wich brand I should note and so on...? Or
should I know create 3 Notes? <br>
How I should go at the kiosk where I can buy stamps for "biber
post", send mail with "Deutsche Post" and parcels with "Deutsche
Post/DHL"? <br>
I've look at the naming of the postal service providers - they
often name them "service points".... <br>
</p>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Tagging mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Tagging@openstreetmap.org">Tagging@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/tagging">https://lists.openstreetmap.org/listinfo/tagging</a>
</pre>
</blockquote>
</body>
</html>