<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 27/02/2021 20:55, Robin Burek wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:c2edd403-a657-6111-a12e-49f3c14f1e59@gmx.de">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"
      cite="mid:c2edd403-a657-6111-a12e-49f3c14f1e59@gmx.de">
      <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 maps.me 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 maps.me, 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 class="moz-txt-link-freetext" href="https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site">https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site</a>
          and
          <br>
          <a class="moz-txt-link-freetext" href="https://wiki.openstreetmap.org/wiki/Relations/Proposed/Cluster">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"
      cite="mid:c2edd403-a657-6111-a12e-49f3c14f1e59@gmx.de">
      <br>
      [1] - <a class="moz-txt-link-freetext" href="https://www.openstreetmap.org/relation/128009">https://www.openstreetmap.org/relation/128009</a>
      <br>
      <br>
      <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>