<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>