Mehrere Attribute an einen Schlüssel?

errt · 2011-07-12T21:10:17.000Z

Im Prinzip sind die cuisine-Werte doch halbwegs brauchbare Zusammenfassungen - zumindest solange man das System nicht falsch versteht und cuisine=ice_cream taggt, nur, weil es das als Nachtisch gibt. Aber es ist schon richtig, dass z.B. pizza und italian getrennt ist.

aighes · 2011-07-12T21:13:07.000Z

An der Komplexität der Renderregel ändert sich doch nichts. Mit cuisine=* muss man amenity=restaurant und cuisine=pizza auswerten und mit *=yes muss man amenity=restaurant und pizza=yes auswerten.

Komplexer wird es, wenn man alle Restaurants mit einer beliebigen cuisine möchte. Aber wozu sollte man sowas wollen?

pizza hat ja nichts damit zutun, dass es auf der Speisekarte steht, sondern sagt aus, dass es sich um eine Pizzeria handelt. So eine typische Pizzabude mit Lieferservice würde ich jedenfalls nicht als Italiener eintragen.

Marqqs · 2011-07-12T21:56:00.000Z

aighes:

Komplexer wird es, wenn man alle Restaurants mit einer beliebigen cuisine möchte. Aber wozu sollte man sowas wollen?

Naja, die Anforderungen sind verschieden, manche wollen genau das:
http://toolserver.org/~stephankn/cuisine/?zoom=17&lat=50.93798&lon=6.95916&layers=BT

Trotzdem, deine Idee mit
pizza=yes
oder auch
cuisine:pizza=yes
find ich gar nicht schlecht.
Schwierig wird es allerdings, wenn man mit einer einfachen SQL-Abfrage die Art der Küche als Value ausgeben will. Dann müsste man alle Tags abklappern. Oder man lässt den Haupt-Tag mit cuisine=pizza zusätzlich drin. Fragen über Fragen.

tippeltappel · 2011-07-12T21:56:13.000Z

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

Fabi2 · 2011-07-13T03:01:35.000Z

badger123:

aighes:

Am einfachsten wäre pizza=yes und sushi=yes

dann aber
cuisine:pizza=yes
cuisine:sushi=yes

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…

_i · 2011-07-13T06:27:15.000Z

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.

Marqqs · 2011-07-13T09:04:08.000Z

Fabi2:

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.

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.

wambacher · 2011-07-13T09:32:33.000Z

Marqqs:

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.

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

Marqqs · 2011-07-13T09:50:52.000Z

wambacher:

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.

EvanE · 2011-07-13T10:20:26.000Z

Marqqs:

Fabi2:

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.

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.

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?

Entweder benutzen sie grundsätzlich den gesamten String => “kennen wir nicht, behandeln wir nicht”.
Oder sie benutzen nur den ersten Teilstring => Nicht ganz untergegangen, aber nur ein Teil berücksichtigt.

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)

wambacher · 2011-07-13T10:24:04.000Z

Marqqs:

Das Zeigt, dass durchaus Bedarf nach einer einheitlichen Lösung da ist.

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

Nop · 2011-07-13T10:35:02.000Z

Marqqs:

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.

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.

Marqqs · 2011-07-13T11:11:42.000Z

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.

hurdygurdyman · 2011-07-13T11:45:34.000Z

Ein schönes Beispiel für die inflationäre Nutzung des Semikolons
http://www.openstreetmap.org/browse/way/62227665

Nawattnu???

ajoessen · 2011-07-13T11:54:40.000Z

hurdygurdyman:

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

EvanE · 2011-07-13T11:54:54.000Z

hurdygurdyman:

Ein schönes Beispiel für die inflationäre Nutzung des Semikolons
http://www.openstreetmap.org/browse/way/62227665

Sieht nach Verbindung von Wegen mit unterschiedlichen EIgenschaften aus.
Wenn man nicht darauf achtet, kommt halt solcher XXX dabei raus.

Edbert (EvanE)

errt · 2011-07-13T14:18:32.000Z

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

Nop · 2011-07-13T14:37:31.000Z

errt:

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

Tordanik · 2011-07-13T15:15:41.000Z

Nop:

errt:

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

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:

als zwei Objekte modellieren, die implizit oder explizit in einer Beziehung stehen
eines der Objekte zum Attribut degradieren

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

Grundsätzlich wollte ich nur wieder mal dran erinnern wie schnell die vermeintlich einfache Lösung mit den ; am Ende ist.

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.

Fabi2 · 2011-07-13T19:28:00.000Z

Marqqs:

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.

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.