Gegen die Trennung von cuisine=italian und cuisine=pizza habe ich nichts einzuwenden.
Nur würde ich bei einer typischen Pizzabude nicht zusätzlich cuisine=sushi angeben. Das sieht für mich dann doch schon sehr nach Speisekarte taggen aus. Dem Italiener “gönnt” dann über kurz oder lang jemand cuisine=pizza;pasta;etc.
Vor solchen “Auswüchsen” “fürchte” ich mich. 
Gruß
tippeltappel
Auf dieses Thema hier habe ich ja schon gewartet! 
Obige Schreibweise ist nach momentanem Stand noch die beste und ausagekräftigste Schreibweise, sofern man den Subkey hinter “:” aus einen beschränkt.
Weil mit “;” als Separator darf man dann immer mühsam die Stecknadel im Heuhaufen suchen, da dauert dann die Verarbeitung der Daten ein Zigfaches, wenn man das auswerten möchte.
Das Problem ist auch das momentan die OSM-API keine Baumstrukturen von Werten abbilden kann, was bei solchen Sachen aber nötig wäre, um das ganze auch halbwegs menschenbenutzbar zu machen.
Aus Schreibfaulheit benutzen eben die Leute lieber: “cuisine=chinese;kebab;pizza” als das bessere cuisine:chinese=yes + cuisine:kebab=yes + cuisine:pizza=yes, weil da muß man ja den Key ständig mehrfach neu schreiben und leider hilft einem da die kaputte JOSM-Vorlagensyntax auch nicht weiter, wenn man zwischen mehreren Keys auswählen können möchte. Da nehmen dann die Leute eben das “;”…
Das Problem mit
key:1=wert1
key:2=wert2
ist das man da auch bei Key:count=2 sich nie darauf verlassen kann, ob es nicht doch Lücken zwischen den Keys gibt, bzw. mehr oder weniger als angegeben vorhanden sind. Vielleicht ist ja nach Key:1=* der nächste erst bei Key:1000=*, weil vielleicht die 999 Keys dazwischen veraltet sind und die von 1000 bis 5000 noch aktuell. Taggt das jetzt mal jemand richtig um? 
Und bei der Auswertung dürft ihr dann eben den ganzen darstellbaren Zahlenbereich abklappern, weil es könnte ja irgendwo noch einen Key geben…
Naja Leute das sind aber Wunschträume und bis jetzt noch nirgendwo proposed oder durchgesetzt. So richtig gefällt mir die lange Schreibweise noch nicht, aber daran solls ja nicht scheitern.
Aber nur, wenn die Datenbank ungeschickt organisiert ist. Intern kann man sowas durchaus performant abbilden. Man braucht nur beim Einlesen der .osm-Datei die cuisine-Zeilen entsprechend zu zerlegen. Aus “cuisine=pizza;sushi” werden dann halt zwei Datenbankeinträge.
Es steht doch nirgends, dass das Datenbank-Schema mit dem Taggingschema oder dem XML-Schema exakt übereinstimmen muss. Meist ist es eh anders strukturiert, weil man die Daten für einen bestimmten Zweck hin optimiert. Zum Beispiel führt osm2pgsql Optimierungen fürs Rendern durch. Bei Routern komm ich mit dem Standardschema auch nicht weit, hier brauch ich ein aufs Routing hin optimiertes Datenbankschema.
Wichtig ist nur, dass die Information eindeutig ist. Wenn man sich auf den relativ leicht handhabbaren Strichpunkt einigt und das entsprechend dokumentiert, ist dieses Datenformat sicher kein unüberwindbares Hindernis für die Software.
Braucht es natürlich nicht, ABER 99% der OSM-ler, die eine “eigene” DB benutzen, machen das entweder mit osm2pgsql und Derivaten zum Rendern oder direkt mit osmosis (simple und snapshot) für andere Sachen.
Für beide Gruppen gibt es fertige “ausgetretene” Wege, die die DB erstellen (Schema!), Rohdaten in die SQL-DB einpflegen und nach Wunsch auch aktuell halten.
Sollen wir die alle ändern? Das halte ich für nicht zumutbar.
Somit bleiben Tags weiterhin einfache Key/Value-Paare (key=value) und je komplexer die Werte werden um so schlimmer wird deren Auswertung.
Wenn du deine eigene DB umbiegst, ist das deine Sache, aber daraus eine Lösung für die Grosse Masse abzuleiten, halte ich nicht für sinnvoll.
Gruss
Walter
Da hast du sicher Recht. Allerdings ist das Array-Problem meiner Ansicht nach nicht zufriedenstellend gelöst. Ich finde, wir dürfen in die Zukunft denken und die Datenstruktur auch weiterentwickeln. Wenn das Anliegen wichtig genug ist, werden eben die Tools entsprechend angepasst. Und abwärtskompatibel ist die Sache sowieso, weil ich, wenn ich die Einzeldaten nicht brauche, dann eben eine Zeichenkette mit Strichpunkten bekomme.
Ich sag ja nicht, dass mein Vorschlag die beste Lösung ist, aber ideal ist der jetzige Zustand wirklich nicht. Das sieht man daran, dass die Strichpunkt-Variante bei manchen Keys offiziell verwendet wird. Mir fallen grad die opening_hours ein. Es gibt aber auch eine Reihe weiterer Beispiele, such einfach mal im OSM-Wiki nach “Strichpunkt”, “Semikolon”, “semicolon”.
Das Zeigt, dass durchaus Bedarf nach einer einheitlichen Lösung da ist.
Das Problem ist nicht der Strichpunkt als Trennzeichen. Ein String lässt sich leicht anhand eines Zeichen in seine Teile zerlegen. Das Problem liegt in der Organisation der Anwendungssoftware.
Heutige OSM-Software geht davon aus, dass ein Objekt einen Schlüssel nur einmal haben kann. Das ist mit einer Werte-Liste als ein String ja erst mal kein Problem. Allerdings wird es zum Problem, wenn man die Werte einzel nutzen will. Dann muss man sich nämlich überlegen, wie man solche Fälle behandeln will.
Was machen die Programmentwickler in diesen Fall?
Zur Zeit arbeitet praktisch (fast) jede OSM-Software so, dass sie nur einen Wert je Schlüssel zulässt. Das ist eine Vereinfachung für die interne Datenstruktur. Ansonsten müsste man für die Schlüssel statt einer Variablen (mit dem Wert) ein Feld (für mehrere Werte eines Schlüssels) vorsehen. Und das bedeutet eine tiefgreifende Umstrukturierung gegenüber dem jetzigen Zustand und wahrscheinlich einen höheren Verarbeitungsaufwand. Dieses Problem besteht unabhängig davon ob man Schlüssel mehrfach zulässt oder eine Werte-Liste je Schlüssel verwendet.
Im Grunde genommen ist ein Konstruktion wie cuisine:pizza=yes nichts anderes als Mehrfachschlüssel über einen Umweg einzuführen. Der Aufwand viele Varianten zu berücksichtigen steigt auf jeden Fall. An welcher Stelle der höhere Aufwand entsteht, mag sich unterscheiden aber der erhöhte Aufwand ist irgendwo zu leisten.
Edbert (EvanE)
Da geb ich dir -leider- recht. Es gibt doch das API-7 Projekt. Da werden solche Sachen diskutiert.
http://wiki.openstreetmap.org/wiki/API_v0.7
Gruss
Walter
Erstens ist es ein enormes Hindernis. Es muß für jedes Tag einzeln gezielt umgesetzt werden. Es muß in jeder Anwendung berücksichtigt werden. Und es gibt reichlich Anwendungen, die direkt auf XML/PBF Daten arbeiten und keine Datenbank zur Verfügung haben, in der sie mal eben schnell irgendwas umstrukturieren könnten. Da explodieren Aufwand, Verarbeitungszeit und Speicherverbrauch.
Zweitens ist die Semikolon-Methode nicht sonderlich weit durchdacht oder tragfähig. Sobald es über ein einziges, allein gültiges und leicht zerlegbares tag hinaus geht, scheitert das Verfahren. Stell Dir vor, Du hast die beliebte Kombination von amenity=restaurant;biergarten oder amenity=hotel;restaurant und cuisine=regional;pizza. Dann ist schon undefiniert ob es die pizza nur im Biergarten gibt bzw. die gut bürgerliche Küche nur im Hotel oder alle Richtungen in allen Örtlichkeiten. Nimm noch abweichende Öffnungszeiten für den Biergarten dazu und das Chaos ist komplett.
Ein vernünftiges Modell für Wertekombinationen ist noch ein ungelöstes Problem. Aber die “einfache” Lösung mit Semikolons ist keine.
Hallo Nop,
hotel gehört zu tourism, das heißt, man kann es gleichzeitig mit amenity=restaurant darstellen. Aber das ändert nichts daran, dass du Recht hast. 
Der Strichpunkt ist eine einfache Lösung für ganz bestimmte Tags, möglicherweise auch für den cuisine-Tag, aber so komplexe Strukturen, wie du sie als Beispiel anführst, lassen sich damit nicht auflösen, das ist richtig.
Vielleicht helfen Relationen dabei: Eine Relation mit name=Posthotel und dann untergeordnet zwei Nodes mit tourism=hotel und amenity=biergarten. Aber nur vielleicht. Weil auch daran scheitern dann viele Programme. Pragmatische Lösung ist da wohl immer noch, zwei getrennte komplette Objekte einzutragen.
Ein schönes Beispiel für die inflationäre Nutzung des Semikolons 
http://www.openstreetmap.org/browse/way/62227665
Nawattnu???
Changset reverten. Das passiert immer, wenn man Äpfel und Birnen zusammenwirft 
Gruß,
ajoessen
Sieht nach Verbindung von Wegen mit unterschiedlichen EIgenschaften aus.
Wenn man nicht darauf achtet, kommt halt solcher XXX dabei raus.
Edbert (EvanE)
@Nop: Wenn es sich um zwei getrennte Objekte handelt (und das tut es meiner Meinung nach, wenn beide unterschiedliche Öffnungszeiten oder deutlich unterschiedliche Speisenauswahl haben), sollte es sowieso als zwei Objekte gemappt werden.
Nicht zwangsläufig. Ich kenne Innenstadtkneipen mit Biergarten, der Biergarten schließt anwohnerbedingt um 22:00, die Kneipe später. Ist aber definitiv nur ein Laden. Ebenso gibt’s Lokale mit Fränkisch+Pizza, oder Chinesisch+Pizza, aber definitiv nur ein Lokal. Das als zwei Objekte auseinanderzufassen wäre falsch, da würde ich annehmen das ist eine Pizzeria im selben Gebäude wie ein Chinese. Das gibt’s ja genauso gut.
Grundsätzlich wollte ich nur wieder mal dran erinnern wie schnell die vermeintlich einfache Lösung mit den ; am Ende ist.
Meine Auffassung: Das ist nicht ein Objekt, das gleichzeitig Kneipe und Biergarten ist, sondern ein Biergarten (Objekt A), der zu einer Kneipe (Objekt B) gehört (Beziehung).
Ein Semikolon dient zur Modellierung mehrerer gleichberechtigter Werte eines Attributs eines Objekts. Es dient nicht zur Zusammenfassung mehrerer Objekte in ein Datenelement. Fast immer, wenn es Schwierigkeiten mit dem Semikolon gibt, funktioniert daher eine von zwei Lösungen:
Oben habe ich z.B. für den Biergarten-Fall eine naheliegende Modellierung der Art #1 angegeben. Ein anderes Beispiel, das gerne genannt wird, ist amenity=bank;atm - was einen misslungenen Versuch darstellt, zu beschreiben, dass zur Ausstattung der Bankfiliale ein Geldautomat gehört:
Lösung Art 1: Bank als Polygon, Geldautomat als Node. Implizite Beziehung dadurch, dass der Node im Inneren des Polygons liegt. Explizite Beziehung durch Relation wäre auch denkbar.
Lösung Art 2: Bank als Hauptobjekt, der Geldautomat wird zum Attribut atm=yes in der Bedeutung “hat einen Geldautomaten”.
Das ist natürlich absolut richtig. Sobald man merkt, dass es Probleme gibt - und das passiert sehr schnell -, sollte man sich eine “richtige” Lösung suchen, statt das Semikolon für Dinge zu verbiegen, die es nicht leisten kann.
Das man das intern anders abbilden kann, stimmt natürlich, aber die Daten müssen ja auch verarbeitet werden…
Da ja “;” ein legitimer Wert im Wert sein kann, braucht man dann noch ein Escaping wenn man die Daten nicht gesplittet haben möchte, z.B. mit “;”. Das führt dann aber dazu, das die API den Wert jedes Schlüssels beim Hochladen parsen und beim Herunterladen dann die getrennten Schlüssel wieder, in der richtigen Reihenfolge (kann ja sein, das der Benutzer sich dabei was gedacht hat), für den Nutzer zusammenbauen muß. Ich bin da der Meinung man kann den API-Server da lieber mit sinnvolleren Sachen beschäftigen.
Das Problem ist nämlich, daß jedes Key=Value-Paar immer jeweils eine unabhängige 1:1-Abbildung ist. Das heißt z.B. “highway=service” und “service=driveway” stehen eigentlich in keinerlei Beziehung zueinander. weil ich kann ja “service=driceway” z.B. auch an eine “amenity=post_pox” taggen. Der Mensch und auch dessen momentanen Auswertung interpretiert aber “highway=service” und "service=driveway als Baum, was dann eigentlich auch als
highway--->service--->driveway
abgebildet werden müßte. Durch die fehlenden Bezüge untereinander bei den 1:1-Schlüssel-Wert-Zuordungen, weiß man bei mehreren Tags im Grunde auch nie wirklich sicher, welche Tags auf welche beziehen und ob es überhaupt einen Zusammenhang zwischen ihnen gibt.
Mit dieser Darstellung wäre dann die Mehrfachküche:
cuisine-+--->pizza
+--->kebab
Momentan muß man so etwas mehr behelfmäßig mit verschachtelten Relationen abbilden (für die sie ja eigentlich nicht wirklich gemacht wurden), weil mit anderen OSM-Objekten läßt sich das derzeit leider nicht realisieren. Ach ja, nur falls jemand nach der Idee hinter den verschachtelten type=health-Relationen gefragt haben sollte…
Ja und es gibt bedarf nach einer einheitlichen Lösung: http://wiki.openstreetmap.org/wiki/API_v0.7#Way_to_get_orphaned_relations_and_represent_tree_style_information_more_properly
Vielleicht ist da noch nicht verständlich genug und jemand möchte das besser schreiben oder ergänzen.
Ich kann mir gerade nicht vorstellen, wann “;” ein legitimer Wert sein kann. Höchstens im name Tag, aber darum geht es ja nicht.
Das Beispiel mit opening_hours=* kam hier ja schon.
ja stimmt. Daran hatte ich gar nicht gedacht. Naja, das ist kein Wert, der bspw osm2pgsql davon abhalten sollte, Geometrien (Nodes, Ways, Polys) bei Semikolons doppelt einzuspielen.