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