Mehrere Attribute an einen Schlüssel?

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.

SunCobalt · 2011-07-13T19:31:41.000Z

Fabi2:

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…

Ich kann mir gerade nicht vorstellen, wann “;” ein legitimer Wert sein kann. Höchstens im name Tag, aber darum geht es ja nicht.

Fabi2 · 2011-07-13T19:39:47.000Z

SunCobalt:

Fabi2:

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…

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.

SunCobalt · 2011-07-13T19:42:03.000Z

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.

errt · 2011-07-13T19:46:43.000Z

Ja, aber da tut es ja im Prinzip auch voneinander getrennte Öffnungszeiten abtrennen. Aber grundsätzlich hast du schon Recht, eine bessere Datenstruktur wäre eine saubere Lösung.

ajoessen · 2011-07-14T06:10:25.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.

Das ist aber nun gerade kein Problem, weil der Biergarten ja vor dem Gebäude ist, die Kneipe aber drinnen.
Also kann man zwei nodes mit verschiedenen tags platzieren.

Gruß,
ajoessen

schlauchboot · 2011-07-14T07:56:48.000Z

ajoessen:

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.

Das ist aber nun gerade kein Problem, weil der Biergarten ja vor dem Gebäude ist, die Kneipe aber drinnen.
Also kann man zwei nodes mit verschiedenen tags platzieren.

Das reicht aber nicht, denn woran würde man z.B. die Kontaktdaten des “Ladens” hängen? Sie würden beide Nodes betreffen. Man hat hier verschiedene Objekte:

Ein Gebäude

Eine Kneipe in einem Teil des Gebäudes

U.U. weitere Läden, Wohnungen etc. in anderen Teilen des Gebäudes

Einen Platz vor dem Gebäude oder in einem Hof, der den Biergarten als Teil enthält.

Diese Objekte haben Ortskoordinaten, können also als Way oder Node abgebildet werden.

Dann gibt es aber noch andere (nur logische) Dinge, wie den “Laden”, der sich aus Kneipe und Biergarten zusammensetzt. Diesen kann man eigentlich nur durch eine Relation zusammenfassen, denn es gibt kein real existierendes Objekt mit Ortskoortinaten, welches genau beides (Kneipe und Biergarten) umschließt. An diese Relation kann man dann z.B. die Kontaktdaten (wie z.B. eine Telefonnummer) hängen (oder eine Handelsregisternummer, einen Inhaber, eine Webseite, … um weitere Beispiele zu nennen). Ich halte es für falsch, die Relation dadurch aufzulösen, daß alle Attribute derselben redundant an beide Nodes gehängt werden. Dann stellt sich aber z.B. weiter die Frage, woran man die Adresse hängt: An das Gebäude (bzw. einen Eingangs-Node) oder an die Relation?

Ich glaube, daß in diesem Thread nun zwei verschiedene Themen behandelt werden, die man vielleicht besser trennen sollte. Denn die Abbildung von real existierenden Objekten mit Koordinaten und von nur logisch vorhandenen Dingen ist ein Thema, “vektorwertige” oder hierarchische Attribute ein anderes. Beides sollte sich immer sauber trennen lassen können.