immer wieder gibt es die Situation, dass ein Geschäft sowohl Brillen als auch Hörgeräte verkauft, sprich eine Kombination aus “shop=optician” und “shop=hearing_aids” ist. Bislang habe ich dafür immer zwei separate Nodes erstellt, vor allem weil es besser ausgewertet werden kann. Außerdem steht im Wiki [1] folgender Satz:
On important “top-level” tags that define what an element is avoid ; separated values whenever possible.
“shop” würde ich zu diesen “top-level” Tags zählen.
Mit diesem Thema hier würde ich gerne in Erfahrung bringen, wie ihr das handhabt und ob man möglicherweise eine Festlegung treffen kann, die dann auch im Wiki ([2], [3]) dokumentiert wird.
Folgende Möglichkeiten gibt es meiner Meinung nach:
zwei separate Nodes mit "shop=optician und “shop=hearing_aids”
ein Node mit “shop=optician;hearing_aids” (Verwendung in Deutschland siehe [4])
ein Node mit “shop=optician” + “hearing_aids=yes”, wenn das Geschäft hauptächlich Brillen verkauft und Hörgeräte “nebenbei” (bzw. umgekehrt “shop=hearing_aids” + “optician=yes”), Verwendung der “Subtags” in Deutschland siehe [5] und [6]
ein Node mit “shop=optician”, Hörgeräte werden ignoriert (bzw. umgekehrt “shop=hearing_aids”, Brillen werden ignoriert)
shop=A + B=yes kann man man machen wenn A überwiegt. Ansonsten gibt es die Möglichkeiten ein Node mit shop=A;B oder zwei Nodes mit shop=A + shop=B zu mappen. Da sollte meiner Meinung nach unterschieden werden.
Ist das Angebot von A und B gleichwertig und sind diese auch räumlich nicht irgendwie getrennt, dann halte ich shop=A;B für die sauberste Lösung aus Datensicht. Auch unterschiedliche Öffnungszeiten für die jeweiligen Angebote können die Variante mit zwei getrennten Nodes rechtfertigen.
Das Argument, dass Renderer bei shop=A;B nicht wissen welches Symbol (A oder B) sie in der Karte darstellen sollen, ist nun wirklich ein Problem des Renderers. Deswegen eine der andere Varianten zu wählen halte ich für “Tagging für den Renderer”.
Ich hätte ein Problem damit festzustellen, was überwiegt.
Ich finde dieses Argument nicht im Wiki-Abschnitt “When NOT to use”, zumindest nicht in der Deutlichkeit. Lediglich “people building software for rendering” werden als Datennutzer genannt, die ein Problem haben könnten.
Das Argument, dass Renderer bei shop=A;B nicht wissen welches Symbol (A oder B) sie in der Karte darstellen sollen, ist nun wirklich ein Problem des Renderers.
die meisten Renderer werden bei shop=A;B gar nichts rendern, weil es keine 1:1 sondern eine 1:n Beziehung ist die nicht erwartet wird.
Dass das unerwünscht ist sieht man daran, dass shop=A und shop=B auf demselben Objekt technisch unterbunden wird.
Ich kenne das Argument aus früheren Diskussionen. Ich finde das im Wiki schon recht deutlich.
Don’t use them in your mapping, and don’t propose them on the wiki if there are better ways of representing things. This is because use of semi-colons as value separators is contrary to the aim of keeping it simple both for data contributors (mappers) and data users. For the sake of new contributors and anyone trying to use the data (people building software for rendering, searching, “find my nearest cafe” mobile apps, etc) we should keep at least basic data directly usable.
Ich finde diesen Satz übrigens nicht richtig. Wir wollen die Realität darstellen, wie sie ist. KISS ist sinnvoll, sollte aber diesen Grundsatz nicht überschreiben. Außerdem halte ich es für absolut KISS, wenn wir einen POI, der sowohl A als auch B ist, auch so als shop=A;B erfassen. Dass diese Forderung genau das Gegenteil von “simple” ist, sehen wir auch an dieser Frage hier.
Das ist ein Henne-Ei-Problem: Was war zuerst da? Der Wunsch, dass es Auswerter möglichst einfach haben oder der Wunsch es gemäß der Realität abzubilden.
der Wunsch, etwas gemäß der Realität abzubilden, “zwingt” einen ja nicht zu einer bestimmten Abbildung (wie tag=A;B), man könnte auch z.B. zwei Objekte machen (tag=A und tag=B) und mit einem weiteren Objekt wieder zusammenfügen
Doch, es ist für Auswerter sehr einfach, neben shop=A auch noch nach A=yes zu suchen, da wäre es schon viel aufwendiger, neben shop=A auch noch in shop=Foo;A;Bar das “A” zu finden. Unmöglich wäre es natürlich nicht, aber die üblichen Tools gehen nicht davon aus, dass sie das tun sollen. Nimm z.B. osmium-tool, wenn du da alle shop=A filtern wolltest und alle A=*, wäre das banal, aber wenn du die shop=A;B suchen wolltest, müsstest du erst alle shop suchen, und in den shops dann noch mal nach “;” suchen und splitten, und dann über die Ergebnisse nochmal drübergehen ob ein shop=A dabei war.
Update: stimmt nicht ganz, ich habe nochmal nachgesehen und osmium-tool kann auch substring-Suchen machen mit “*”, d.h. man könnte es etwas einfacher haben indem man im ersten Schritt nach shop=*A* sucht anstatt nach shop=*, aber ansonsten ist der Weg gleich
Ich habe auch nicht geschrieben, dass es nicht geht oder einfach ist. Aber die Behauptung man solle nicht shop=A;B sondern lieber shop=A + B=yes taggen, weil das einfacher in der Auswertung sei, ist falsch.
ist sie nicht, sie ist richtig, für die Auswertung ist es so einfacher.
Abgesehen davon kann man auch fragen, ob ein Y=A;B nicht vielleicht was anderes ist als ein Y=A und ein Y=B zusammen, und darum auch gleich einen neuen Tag vergeben.
Z.b. kann man einen highway=footway;cycleway nicht einfach behandeln wie einen footway als Fußgänger und einen Cycleway als Radfahrer, weil es einen Unterschied macht, ob es ein reiner Fußweg ist oder ein Fußweg auf dem Fahrräder fahren (bzw. vice versa)
Nach einer Woche haben 14 User abgestimmt, 43 % sprechen sich für Variante 2 (Werte mit Semikolon getrennt) aus.
Ich lasse die Abstimmung noch eine Woche (bis 08.10.) offen. Danach würde ich das Ergebnis auf den entsprechenden Wiki-Seiten als Tagging-Empfehlung eintragen.
Nochmal bei den Ergebnissen auf “Abstimmen” klicken und dann eine andere Wahl treffen. Oder “Abstimmung zurücknehmen” um die Stimme komplett zurück zu nehmen.
Das Problem ergibt sich auch schon bei z.B. node{amenity=cafe, shop=bakery}. OsmAnd z.B. hat sich halt einfach für ein Symbol entschieden und gut ist, und in der kategorischen Suche findet man den Shop sowohl unter “Cafe” als auch “Bäckerei”. Eigentlich ganz pragmatisch gelöst.
Wie erwähnt ist das größere Problem, dass ‘;’-separierte Listen von vielem nicht verarbeitet werden. Vielleicht hätte das OSM-Datenmodell mit “echten” Multivalues entworfen werden sollen (denkbar wären Ansätze wie man sie in LDAP oder MAPI findet), aber letztendlich haben alle Varianten ihre eigenen Schwierigkeiten.
Mein Problem mit „;“ ist, dass man nur ein Objekt hat, um Attribute zu pflegen. Also im Prinzip das gleiche Thema wie Radweg an der Straße vs. Radweg als eigenen Highway: Das ist immer solange gut, wie nix besonderes anliegt. Und dann kommen Bauarbeiten, die nur eins davon betreffen.
An dem shop hat man dann z.B. halt nur eine Öffnungszeit, eine brand,…
Die Variante sollte man auch nur anwenden, wenn es ein Geschäft ist, dass beides gleichermaßen anbietet und eine Unterscheidung nicht möglich/sinnvoll ist.
für mich sind da die Grenzen fließend… Das ist je nach Gutdünken und Interpretation des Mapper eine unterschiedliche Sichtweise… Meiner Meinung nach sollte es datenbankabfragetechnisch hinreichend ausreichend sein, wenn die semikolongetrennten Werte in sich standartisiert sind.
Ich unterscheide aber hier:
ist für mich Quatsch mit Soße…
Aber
ist häufig zu finden…
Das beträfe auch die hier eingangs gefragte Kombination…
Für mich auch hier wieder: OSM ist eine Datenbank, keine Karte! Was die Karte darstellen möchte ist sicher das eine, viel wichtiger ist das, was ich aus der Datenbank abfragen kann und dann darstellen möchte!!!
Ich kann mir z.B. vorstellen, daß ein (spezieller) Renderer bei einem solchen Node mit semikolongetrennten Werten je nach Zoomstufe zwei, zum Punkt zugehörige unterschiedliche Symbole anzeigt, was das Geschäft anbietet…
