Mehrere Attribute an einen Schlüssel?

errt · 2011-07-12T20:36:02.000Z

Marqqs:

Strukturell sauber wäre z.B. das hier:
cuisine=pizza
cuisine:2=sushi
cuisine:3=kebap
usw.

Also das finde ich nun ganz und gar unbrauchbar. Wesentlich schlimmer als die Strichpunktschreibweise, die nur daran leidet, dass kein Programm sie auswertet (obwohl das ja im Prinzip nicht so schwer wäre). Allerdings ist das Problem der meisten Programme wohl weniger daran liegt, dass es grundsätzlich zu kompliziert wäre, das zu zerlegen, als dass sich vielmehr die Frage stellt, wie man sowas darstellen soll.

tippeltappel · 2011-07-12T20:55:03.000Z

Marqqs:

TheFive:

Ich würde hier auch die “Hauptattraktion” taggen.

Die opengastromap.de zeigt bei cuisine=pizza;sushi das Pizza-Symbol an, die Karte wertet also immer nur das aus, was vor dem Strichpunkt steht. Sauber ist diese Art zu taggen allerdings nicht. Es ist quasi eine Art hstore auf der Ebene des Datenbankschemas.

Strukturell sauber wäre z.B. das hier:
cuisine=pizza
cuisine:2=sushi
cuisine:3=kebap
usw.

Aber gegen eine grundsätzliche Einführung des Strichpunkts als Trenner hätte ich auch nichts. Das heißt ja nicht, dass es dann in dieser Form in der Datenbank stehen muss. Dort kann man solche Konstrukte dann als Array abspeichern. Da könnte man jetzt endlos weiterphilosophieren…

Und wie baut man mit

cuisine=*
cuisine:2=*
cuisine:3=*

sinnvolle Renderregeln? grübel

*=yes
erfordern sehr detaillierte Renderregeln. Sie hätten aber den Vorteil, daß man bei Bedarf
amenity=restaurant
cuisine:pizza=yes
mit Ersetzungsregel “greifen” und in einem Spezialitätenführer anzeigen lassen kann.

Nachteil:
Das System verleitet dazu, die halbe Speisekarte zu taggen.
Und wer hält das nach?
Sinnvolle Zusammenfassungen wie
cuisine=international
cuisine=italian
cuisine=greece
etc.
wären klarer.

Gruß
tippeltappel

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.