<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><font face="Verdana">It was not intended as to be the one and
        only solution, just an example how it was solved here long time
        ago with what was available at that time, and for sure as I said
        before lots of room for improvement.  <br>
        I totally agree, if there is a one and single same service
        provided, there is nothing against using multiple values in
        attributes for the same service. That isn't feasible in many
        multi-disciplinary places if you try to tag them with multiple
        different top level keys.  But as marc_marc said, we've passed
        that point. <br>
        1 or 2 nodes or even more nodes I think is best practice to be
        guided by the concept if we can define the one node with a
        single value for the top level key, covering all the services
        provided, if that isn't clear use more nodes. Carefully consider
        that on a case by case bass but don't favour or exclude one or
        the other, just give some guidance to make it as simple as
        possible.  Attributes like brand or owner names, if the service
        is identical to the one chosen as top level key, of course, go
        for it.  It should be a one to many, not a many to one or many
        to many relationship.<br>
        If they differ however, then you would split again, it's a
        different feature in the map, a different service for which we
        have a different top-level tag. It needs to be considered on a
        case by case basis.<br>
        At present, I would favour also to use a relation to link
        different services to one single place of service, not the
        relationship by manipulating and duplicating the names. Just to
        avoid duplicating data but also to make the link more explicit.</font></p>
    <p><font face="Verdana">Greetings,</font></p>
    <p><font face="Verdana">Bert Araali</font><br>
    </p>
    <div class="moz-cite-prefix">On 27/02/2021 21:52, Joseph Eisenberg
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAP_2vPhHPgeg32nq==bFYXd3Ukbvi7yQ8mPSumCziHUB_pMtMg@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div dir="ltr">
          <div dir="ltr">> " if a shop provides postal services from
            company A as well as from company B, again we split it in
            different nodes with owner (owner of the service provided
            since the shop is a licensor, brand=* is another candidate)
            is owner=Company A and another node with owner=Company B"</div>
          <div dir="ltr"><br>
          </div>
          <div>I believe this is incorrect. </div>
          <div><br>
          </div>
          <div>It is totally fine to use multiple values with a
            semicolon in property tags like network="Company A;Company
            B" so that a single counter which provides services from two
            different systems can be mapped properly, e.g. a
            mobile phone shop which sells SIM cards and service refills
            for two different mobile phone systems.</div>
          <div><br>
          </div>
          <div>Using two different "owner=" tags seems incorrect,
            because we are talking about one shop or one service counter
            in a shop, which has one local owner. </div>
          <div><br>
          </div>
          <div>(The case where I might use two different nodes would be
            something like this Orange Julius and Dairy Queen in
            Singapore: they share a building and employees but have two
            different counters right next to each other: <a
href="https://en.wikipedia.org/wiki/Orange_Julius#/media/File:Orange_Julius-SG.JPG"
              moz-do-not-send="true">https://en.wikipedia.org/wiki/Orange_Julius#/media/File:Orange_Julius-SG.JPG</a>
            - this way you can have each brand=* separately, a few
            meters apart. The alternative of "brand"="Orange
            Julius;Dairy Queen" seems worse, though I would not fault
            anyone who mapped it as a single shop with a semicolon for
            the brand=  and name=)</div>
          <div><br>
          </div>
          <div>-- Joseph Eisenberg</div>
          <div><br>
          </div>
          <div>-- Joseph EIsenberg</div>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Sat, Feb 27, 2021 at 10:18
          AM Bert -Araali- Van Opstal <<a
            href="mailto:bert.araali.afritastic@gmail.com"
            moz-do-not-send="true">bert.araali.afritastic@gmail.com</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
          <div>
            <p><br>
            </p>
            <div>On 27/02/2021 20:55, Robin Burek wrote:<br>
            </div>
            <blockquote type="cite">I could cry.... <br>
              <br>
              <br>
              <blockquote type="cite">Very true, same here, but that
                shoudn't stop you from using different <br>
                nodes which are closely mapped to each other. When
                someone searches <br>
                for a specific service they will show up on the same
                screen. It makes <br>
                it also a feasible concept and easy to understand for
                beginner mappers. <br>
              </blockquote>
              <br>
              Than it is mapping for the randerer. You create extra
              nodes to show <br>
              multiple services of one shop/amenity etc. to display it
              on the map. <br>
              And really - I don't understand it after years. Why should
              I map an shop <br>
              four or five times?!?! There is only ONE SHOP. <br>
            </blockquote>
            Nope, we don't tag primarily for tagging, we use different
            nodes to avoid duplicating data, to avoid to have to add
            multiple values in the same key. The rendering is a nice
            positive side effect. It's ONE shop with multiple services
            or is it ONE service supplied at ONE place.  This concept is
            used in other cases. <br>
            <blockquote type="cite"> <br>
              <br>
              <blockquote type="cite">
                <blockquote type="cite"> <br>
                  <blockquote type="cite">We also considered using
                    relations for this to avoid <br>
                    duplicate names, but at the time didn't seem a good
                    idea because most <br>
                    data consumers didn't process relations. <br>
                  </blockquote>
                  <br>
                  Relations sound interesting as they avoid duplicate
                  data AND make clear <br>
                  that several different features are belonging together
                  AND it works for <br>
                  all kinds of features in OSM (relation/way/point). <br>
                  <br>
                  Do you know how data consumers respond to it nowadays,
                  e.g. when <br>
                  searching for such a feature in <a
                    href="http://maps.me" target="_blank"
                    moz-do-not-send="true">maps.me</a> or OsmAnd or
                  Locus, do they <br>
                  display e.g. the opening hours of the relation, or do
                  they at least show <br>
                  the point is part of a relation and thus you can look
                  up the opening <br>
                  hours manually (e.g. by following a link from point to
                  relation)? <br>
                </blockquote>
                <br>
                We still provide the names of the service owners in the
                name fields, <br>
                because some users might prefer Company A instead of
                Company B and <br>
                some licensors provide the same service for different
                brands.  This <br>
                concept was developed initially by a HOTOSM project.  So
                they use the <br>
                standard humanitarian mapping on OSM and Nominatim.  I
                don't know if <br>
                Nominatim does support searching in owner and operator
                keys now, At <br>
                the time this concept was developed it was not the case
                however like <br>
                f.i. with <a href="http://maps.me" target="_blank"
                  moz-do-not-send="true">maps.me</a>, I don't know if
                that has evolved in the mean time, <br>
                neither for the other ones.  It is however the reason
                why we still <br>
                duplicate the service owner names in the name fields,
                which is not an <br>
                advisable good practice but makes it work in most data
                consumers and <br>
                rendering. <br>
                <blockquote type="cite"> <br>
                  <blockquote type="cite">But we have some candidates
                    like relation=site, relation=cluster <br>
                  </blockquote>
                  <br>
                  I found only the proposals under way <br>
                  <a
                    href="https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site"
                    target="_blank" moz-do-not-send="true">https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site</a>
                  and <br>
                  <a
                    href="https://wiki.openstreetmap.org/wiki/Relations/Proposed/Cluster"
                    target="_blank" moz-do-not-send="true">https://wiki.openstreetmap.org/wiki/Relations/Proposed/Cluster</a>
                  despite <br>
                  >>100k uses?! Amazing. <br>
                  <br>
                  I think relation=site would be suited for the postal
                  partner case. <br>
                </blockquote>
                True, they do exist since long time, developed when
                there was a need <br>
                to develop parent-child relations which never got well
                documented.  <br>
                We have a big improvement to make in that.  We didn't
                consider it as <br>
                a feasible solution because the names of these relations
                (site / <br>
                cluster but also group which is somehow identical to
                cluster) don't <br>
                show up in any rendering in OSM.� <br>
              </blockquote>
              The problem is - when and where you want to display the
              name on wide <br>
              range sites like [1] - but it is a different problem that
              is not <br>
              supposed to be discussed here. <br>
            </blockquote>
            Agree, no need to discuss that here, just wanted to give it
            as a justification why it was not considered as feasible in
            that particular project, because it's not rendered, but we
            don't tag for the renderer ! <br>
            However, although we all agree with that concept, many
            consider other tagging schemes, not relations as more
            favourable without saying explicitly it's because of
            rendering issues.<br>
            <blockquote type="cite"> <br>
              [1] - <a
                href="https://www.openstreetmap.org/relation/128009"
                target="_blank" moz-do-not-send="true">https://www.openstreetmap.org/relation/128009</a>
              <br>
              <br>
              <br>
              <fieldset></fieldset>
              <pre>_______________________________________________
Tagging mailing list
<a href="mailto:Tagging@openstreetmap.org" target="_blank" moz-do-not-send="true">Tagging@openstreetmap.org</a>
<a href="https://lists.openstreetmap.org/listinfo/tagging" target="_blank" moz-do-not-send="true">https://lists.openstreetmap.org/listinfo/tagging</a>
</pre>
            </blockquote>
          </div>
          _______________________________________________<br>
          Tagging mailing list<br>
          <a href="mailto:Tagging@openstreetmap.org" target="_blank"
            moz-do-not-send="true">Tagging@openstreetmap.org</a><br>
          <a href="https://lists.openstreetmap.org/listinfo/tagging"
            rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.openstreetmap.org/listinfo/tagging</a><br>
        </blockquote>
      </div>
      <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>