<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><font face="Verdana">I think we are getting your point Rubik, and
it's a problem of data consistency, which is not implemented in
our data structures versus a system, like Georg already
explained professionally, as an alternative: allowing multiple
values in top level keys / agreeing on value combinations.
Since our data structure is set up as supporting only uniique
values do we want to end up with endless lists of values because
there are millions of combined services around the world. Is
that where we want to go?<br>
Or regard a relation as the one shop containing several nodes as
services, there is just no way to define it otherwise, the nodes
are data containers, not in the strict sense additional spatial
information. <br>
</font></p>
<p><font face="Verdana">Using relations in this context could
support in better data consistency, it doesn't enforce it but at
least in JOSM when I delete a relation or delete an element in a
relation I get a warning that it might compromise data
consistency. I am not a favourite of using spatial
relationships to create these links, because non-spatial data
consumers will not be able to process these and this type of
multiple node usage coudl create some confusion in rendering.
The nodes are more like singular data containers, again because
of our data model. No one stops a renderer however to render the
relation as a single POI on a map and consider those individual
nodes, contained in the relation as just data containers.<br>
</font></p>
<p><font face="Verdana">I don't think neither of both (or the three)
can ever offer a water tight solution or satisfy everyone. But
if we want to tag these kind of features, and I think we should,
it's rather making a choice between bad or not complete
alternatives: <br>
</font></p>
<p><font face="Verdana">- we want to evolve into a model with
millions of unique keys trying to define all kinds of combined
uses</font></p>
<p><font face="Verdana">or</font></p>
<p><font face="Verdana">- a more relational model that can support
some data consistency through validations in our editors, which
we already have.</font></p>
<p><font face="Verdana">or we allow both to co-exist which makes the
whole model even more complex ?</font></p>
<p><font face="Verdana">Greetings,</font></p>
<p><font face="Verdana">Bert Araali</font><br>
</p>
<div class="moz-cite-prefix">On 28/02/2021 00:26, Robin Burek wrote:<br>
</div>
<blockquote type="cite"
cite="mid:d0f780fe-8841-6f3e-72ef-e5788802da23@gmx.de">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">Am 27.02.2021 um 22:08 schrieb Martin
Koppenhoefer:<br>
</div>
<blockquote type="cite"
cite="mid:0D48F037-61CD-4B2B-A279-B3A66BC84A5C@gmail.com">it
depends on the semantics we imply for our tags. How important is
it to know whether it is one shop or two, at the same place<br>
</blockquote>
<p>I think it is very important. And heres a example: A week ago I
was standing in Berlin searched for a post partner-store, that
was disclaimed as an "post_office" in OSM. Hell and there was
nothing at all.... And why? Yeah, the real shop was closed two
years ago. Thanks! <span class="VIiyi" lang="en"><span
class="JLqJ4b ChMk0b" data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="0"><span>Due
to two nodes it causes an error at some point - stupid,
now it hit me again.</span></span></span> <span
class="VIiyi" lang="en"><span class="JLqJ4b ChMk0b"
data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="2"><span>But
it further reinforces the fact that setting multiple nodes
does not make sense.</span></span></span> <span
class="VIiyi" lang="en"><span class="JLqJ4b ChMk0b"
data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="4"><span>And
I refer to it again - a shop-in-shop is not meant!</span></span></span>
<br>
<br>
<span class="VIiyi" lang="en"><span class="JLqJ4b ChMk0b"
data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="0"><span>And
if your argument goes like you called before, then you
have to list each meat or cheese counter individually.</span></span>
<span class="JLqJ4b ChMk0b"
data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="1"><span>These
are own services... <br>
</span></span></span> </p>
<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>