<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">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">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">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">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">https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site</a>
and
<br>
<a href="https://wiki.openstreetmap.org/wiki/Relations/Proposed/Cluster" target="_blank">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">https://www.openstreetmap.org/relation/128009</a>
<br>
<br>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Tagging mailing list
<a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a>
<a href="https://lists.openstreetmap.org/listinfo/tagging" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div>