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