Warum will man mich eigentlich unbedingt falsch verstehen?
Die Abfolge einfacher mit Doppelpunkt getrennter Bedingungen kann natürlich so bleiben wie bisher. Daher kann man weiter maxspeed:motor_vehicle:wet=60 benutzen. Nur wenn es kompliziertere Fälle gibt, wie insbesondere bei den Zeiteinschränkungen müsste man mit Unterschlüsseln arbeiten. Dabei kann man durchaus statt Bedingung-xx auch eine Bedingungsklasse wie Zeit-xx verwenden.
Es läuft auf zwei Bedingungen per Subkey hinaus:
maxspeed=80
maxspeed:motor_vehicle:wet=60
maxspeed=hgv:time1=50
maxspeed=hgv:wet:time1=30
time1=Mo-Fr 07:00-16:00
In diesem Beispiel kommt man sogar mit einer (Zeit-)Angabe aus, da die Werte identisch sind.
Bitte nochmal darüber nachdenken:
Im Schlüssel waren bisher keine komplexeren Analysen notwendig.
Im Wert war das auch bisher schon ggfs. notwendig.
Ich sehe keinen Vorteil darin, das jetzt sowohl für die Werte als auch für Schlüssel machen zu müssen. Dabei geht es nicht um den Rechenaufwand (der ist bei beiden Varianten vergleichbar), sondern mehr um eine saubere Datenstruktur. Andernfalls würde die Programmstruktur unnötig aufwendiger, da Variablen-Auswertung dann auch im Schlüssel eingebaut werden müsste.
Edbert, aber auch time* ist genauso ein variabler String wie Mo-Fr 07:00-16:00. Nur die Länge ist unterschiedlich. Von daher sehe ich immer noch keinen Vorteil darin, das Key-Value-Paar zu zerpflücken. Ich hatte es weiter vorne schon geschrieben. Wenn es fürs Parsen sinnvoll sein sollte, könnte man einen festen Beginn der variablen Teile einfügen.
Bsp: maxspeed:hgv:time(Mo-Fr 07:00-16:00)=50
Der String time ist fix, da keine Zahlen angehängt werden müssen und es ist für den Parser klar, was er mit dem String in den Klammern machen muss.
Btw: Für dieses “Zeug” wird man ohnehin einen neuen Parser schreiben müssen. Das bekommen die aktuell gebräuchlichen Parser nicht gebacken. Dafür sind die Key-Value-Paare, egal wie man sie nun verpackt einfach zu vielseitig. Oder man braucht viele Regeln…
Wie auch immer das Problem, dass wir in diesem Fall statt des bei OSM üblichen Schlüssel/Wert Paar eine Tripple Schlüssel/Bedingung/Wert haben, welches wir irgendwie in das Schlüssel/Wert Paar einbringen müssen, bleibt bestehen.
Alle Lösungsansätze sind insoweit auch Krücken. Ich finde allerdings, dass ein variabler Wert im Schlüssel nichts zu suchen hat.
Welche Lösung sich irgendwann durchsetzen wird, es bleibt das Problem für Anwendungen, dass es mehrere Werte für einen Grundschlüssel geben kann. Und darauf sind (meiner unvollständigen Kenntnis nach) bisher keine Programme ausgelegt.
Ich denke, dass ich von meiner Seite aus nichts mehr zur bisherigen Diskussion beitragen kann.
Ja, die Wiederverwendbarkeit langer Würste spricht für die Auslagerung in einen Value.
Nicht nur die Länge, sondern auch der Zeichenvorrat. Bisher haben wir in Schlüsseln Kleinbuchstaben, Ziffern, Unterstrich und als Begrenzer Doppelpunkte. Mit der vorgeschlagenen Erweiterung kommen Klammern, Leerzeichen, Großbuchstaben, Minuszeichen, Größer- und Kleinerzeichen, Pluszeichen, Schrägstrich, Beistrich und Strichpunkt dazu, ganz zu schweigen vom Doppelpunkt:
Die ersten 2 Doppelpunkte haben eine andere Priorität als die in der Uhrzeit. Ein Parser muss den Schlüssel an Doppelpunkten zerlegen, aber nur an solchen, die außerhalb von Klammern liegen.
Wie oft kommt das denn vor? Meiner Meinung nach nicht oft genug, dass sich dafür ein eigenes programmiersprachen-artiges Konstrukt (Definition von Konstanten) lohnen würde.
Die Sonderzeichen sind zwar ein gültiges Argument, aber das ist etwas anderes als der bisherige Hauptkritikpunkt in der Diskussion: dass einfach gestrickte Software, die auf eine überschaubare Liste relevanter Schlüssel ohne reguläre Ausdrücke, Wildcards o.ä. setzt, überfordert wäre. Daran ändert condX/timeX nichts, denn wenn die Schlüssel nummerierte Verweise auf anderswo definierte Bedingungen enthalten, ließe sich weiterhin keine solche Liste erstellen.
Eine Software, die z.B. eine Tabellenspalte für jeden relevanten Schlüssel anlegen will, käme damit kaum besser klar als mit direkt im Schlüssel verpackten Bedingungen. Übrigens wäre sogar das Verketten von Bedingungen nach Art von maxspeed:hgv:wet für solche Software schon problematisch. Denn auch dort müsste der Auswerter damit klarkommen, dass maxspeed:hgv:wet und maxspeed:wet:hgv äquivalent sind und es so eine potentiell riesige Anzahl von Kombinationsmöglichkeiten gibt (maxspeed:forward:wet:hgv, maxspeed:wet:forward:hgv, …).
Wenn man diese Nachteile akzeptiert und bereit ist, die Software entsprechend anzupassen, dann kann man das “Extended conditions”-Proposal nutzen. Wenn man diese Nachteile nicht akzeptiert, muss man auf eine Lösung setzen, bei der Bedingungen komplett im Wert landen. Den variablen Schlüsselteil nur zu verkürzen reicht nicht - viele Probleme “komplexer” Schlüssel blieben damit weiter bestehen.
Oh, und ein Nachtrag: Auch wenn ich es erst überlesen habe, finde ich es schon interessant, dass du “Ziffern” in die Liste der angeblich üblichen Zeichen in Keys geschmuggelt hast.
In Postgresql (die Datenbank, die OSM intern verwendet) werden die Tags in der Form Key = Value abgelegt. Im Simple/Snapshot-Schema wird dafür der sog. HSTORE verwendet; das ist eine Datenstruktur zum Ablegen beliebig vieler Informationen zu einem Objekt (z.B. die Tags eines Nodes/Ways).
Alle Postgresql-spezifischen HSTORE-Abfragen, Änderungen, Indizierungen - halt alles- kann nur mit kompletten Keys umgehen, wogegen die Values beliebig sein können. [1]
Abfragen wie “Liste all Nodes mit dem Key ‘maxspeed’ oder ‘maxspeed:wet’” sind absolut kein Problem, aber eine Abfrage "Liste alle Nodes mit ‘maxspeed%’ " gehen nicht! (% ist die wildcard für sql).
Abfrage nach den Werten (das was hinter dem = steht) sind ebenfalls leicht und performant machbar.
In anderen Worten: Die Datenbank, auf der die gesammten OSM-Daten gehalten werden, unterstützt keine variablen Keys beim Tagging. Sie lassen sich zwar abspeichern aber nicht mehr abfragen. Und das ist auch nicht durch uns änderbar; da müste man die Postgresql-Entwickler erst einmal überzeugen.
Mir ist klar, dass nicht jeder mit Postgresql arbeitet, sondern viele sich “irgendwie” mit Perl, CC+ oder Python, … durchhangeln aber bei grossen Datenmengen ist die Benutung einer “richtigen” Datenbank mit deren Query-Sprache nun mal unumgänglich. Alles andere ist leider nicht professionell.
ist bspw wet nicht auch eine Bedingung? Die müsste dann konsequenter Weise auch in den Value? Das würde Auswirkungen auf recht viele mit : getrennten und bestehenden Tags mit Bedingung nach dem Doppelpunkt haben.
nee, das ist keine Bedingung (obwohl der Mensch denkt “Maxspeed WENN es nass ist”)
mir ging es nur um die Sachen mit den Namensräumen z.B. addr:city=* oder contact:website=*
die sind ja von der Syntax etabliert und machen keine Probleme. da passt maxspeed:wet und ähnliches prima rein.
Es ist verdammt schwer, sowas wie **select … when key like ‘maxspeed%’ **hinzukriegen während select … where key = ‘maxspeed:wet’ prima geht.
Gruss
Walter
p.s. es mag sein, dass es mit der zum Rendern verwendeten Datenbankstruktur (osm2pgsql) einfacher möglich ist, aber es handelt sich hierbei um eine “abgeleitet” Datenbank in einem angepassten Spezialformat, dass nicht universell ist. Hier ist ja auch das Verarbeiten von MP einfacher, da der Konverter schon das meiste erledigt hat.
Natürlich ist das eine Bedingung! Oder was denkst du, warum der Schlüssel maxspeed:wet mit dem Proposal “Conditions für access tags” (“Bedingungen für access-Tags”) eingeführt wurde?
Wenn du manche Bedingungen im Schlüssel und manche im Wert haben willst, dann sag das halt.
Du musst aber schon zugeben, dass es jeder Logik widerspricht, bei einer Bedingung, die einen fixen String hat es so zu machen und in allen anderen Fällen anders…
nein, weil maxspeed:wet genausowenig eine Bedingung ist wie addr:city.
beides sind einfache Strings, die als Key in der OSM-DB verwendet werden und mit vertretbaren Mitteln nur auf Gleichheit oder Existenz in einer Liste “is in(…)” überprüft werden können.
Leute, es macht überhaupt keinen Sinn, wenn Ihr mit
logischen Bedingungen für OSM-Tags
und
variablen Bezeichnern in SQL-Datenbank-Schlüsseln
aneinander vorbei und Euch die Köppe heiß redet.
Ob eine logische Bedingung bei OSM im Key oder im Value steckt und wie sie jeweils einzeln ausgewertet wird, kann jede Applikation für sich abhandeln.
Aber dass von Walter angesprochene Problem der variablen Datenbank-Schlüssel (die halt den OSM-Keys entsprechen) und deren Abfrage bleibt grundsätzlich bestehen.
Ergo:
Variable Bedingungen im Key führen dazu, dass sinnvolle Datenbank-Abfragen nicht mehr möglich sind und die ganze Auswertung entsprechender Keys auf “Prüfe alle Schlüssel der Datenbank auf deren Inhalt und parse ihn” ins Steinzeitalter zurückfällt.
Variable Bedingungen im Value bleiben dagegen reine Sache der Applikation.
Und das ist in meinen Augen ein KO-Kriterium gegen die variablen Bedingungen im Key, seien es nun “cond1, cond2, …” oder ausgeschriebene Zeitangaben.
maxspeed:hgv:wet enthält zwar eine logische Bedingung für OSM, ist aber eben kein variabler Schlüssel im Datenbank-Sinn, da sein Name fest definiert ist.
ähm, hgv ist genauso eine Variable wie die Uhrzeit. Sie ist eine Variable der Fahrzeugklasse…hgv, psv, goods, taxi…was auch immer. Nur gibt es dort weniger Möglichkeiten als bei Uhrzeit und Gewicht. Dein Vorschlag wäre also, variable Bedingungen erst ab einer bestimmten Menge nach rechts zu schieben.
Ich muss ehrlich sagen, dass die Sache für mich zu komplex geworden ist, daher werde ich (derzeit) auch nicht abstimmen.
Obiges klingt für mich aber nach einem K.O.-Kriterium. Mich würde daher interessieren: Kann jemand das von Walter angesprochene Problem zugunsten des Proposals lösen oder nicht? Damit meine ich einen tatsächlichen Query-Test (PGSQL & HSTORE), keine Aussagen wie “das sollte theoretisch gehen”.
Übrigens habe ich dies hier gerade auch auf der Tagging-Liste gepostet - im Halbdelirium zunächst auf Deutsch … … und dann noch einmal auf Englisch, wofür ich Auszüge von Walter und Georgs Posts übersetzt habe.
Das scheint mir leider auch so.
Außerdem halte ich das mögliche Vorkommen von Doppelpunkten “:” im Key, welche nicht den bisherigen Zweck haben, für unglücklich.
Andererseits finde ich die Idee hinter dem Vorschlag gut.
Lässt sich das Problem irgendwie sinnvoll lösen, ohne die API zu ändern?
