<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><font face="Verdana">I agree, it is a mess, but trying to solve
that now in this proposal seems to me as a very bad idea. <br>
</font></p>
<p><font face="Verdana">@georg</font></p>
<p><font face="Verdana">I thought I've given this explanation how we
solved a similar concept:<br>
In Africa we use mobile_money. A digital wallet service
provided by all telecom providers. They are not banks, but all
telecom services have local licensors where you can physically
deposit and collect cash. These local licensors can very
broadly, they can be dedicated, kiosks, supermarkets, banks and
even some ATM's. However most of them don't have seprate
counters and deliver the services additionally to there main
activities.<br>
We struggled with the same issue as you did, they are not banks,
yet they deliver a service, we didn't want multiple values in
main keys like shop=* or amenity. So we decided it is not wrong
to use a separate tag to describe a distinctive secondary
service. The value we used is mostly bureaux_de_change,
money_exchange. We change digital money into cash. Same could be
applied for your case, you create separate nodes which have a
separate key. <br>
The relationship or link to the main activities of these service
providers is by putting these nodes within the same building.
You can give the building the shop name and the nodes within the
building, either can have the same name, which is of course not
so optimal because you create duplicated data, or a variant like
adding that particular service to the name. F.i. the building
would carry the name = Shopright A, it contains a
shop=supermarket node with the name=Shopright Supermarket, and
another node amenity=post_office or office=courier as you like
with the name=Shopright Postal service or Postal service by
Shopright. We also considered using relations for this to avoid
duplicate names, but at the time didn't seem a good idea because
most data consumers didn't process relations. But we have some
candidates like relation=site, relation=cluster (you consider it
as a cluster of services provided by one shop, the name is
unique and defined in the relation. Surely room for
improvement. <br>
To summarize: I don't see any objections or discouragement to
use different nodes for different services, although in the
ground truth they are served from the same counter, but mostly
indivdiually signposted. So not really a violation of the
general OSM principles in my honest opinion.<br>
</font></p>
<div class="moz-cite-prefix">On 27/02/2021 18:18, Marc_marc wrote:<br>
</div>
<blockquote type="cite"
cite="mid:8574b5c2-eff8-9608-dde6-0220bd5ae00c@mailo.com">
<pre class="moz-quote-pre" wrap="">Le 27.02.21 à 16:09, Georg a écrit :
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">office=courier has a purpose closely related to
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
the office=* key is being a mess with both
internal company offices
and
"service stores" like office=insurance (it's more like a shop=*)
_______________________________________________
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>