@mmd: Es ist immer ein Henne-Ei-Problem: Was nutzt es Dinge einzutragen, die keiner auswertet vs. Was nutzt es Dinge auszuwerten, die keiner einträgt. Ansonsten sehe ich das schon auch teilweise für Garminkarten als hilfreich an. Evtl. bringt es dir nicht viel, weil du keinen LKW fährst etc. Von daher wäre ich immer auch etwas Vorsichtig mit der Bezeichnung “Spezialkarte”. Denn letzlich ist jede Karte nur eine Spezialkarte, da sie nur ein Spektrum abdeckt.
“Spezialkarte” war natürlich nicht abwertend gemeint, sondern einfach nur eine Karte für eine definierte Benutzergruppe. Für LKW und Garmin kenne ich da aktuell nur die Karte von Win32netsky. Kann aber gut sein, dass es da noch weitere gibt, die mir einfach nicht bekannt sind.
Ich muß schon sagen, dass ich gerade mit den komplexen opening_hours im Key oder auch im Value so meine Probleme habe und dort recht heftigen Wildwuchs befürchte, wenn da nicht von Anfang an rigide Prüfungen im Editor vorgesehen werden. Natürlich kann man jetzt argumentieren, dass die opening_hours an anderer Stelle schon etabliert sind, das macht sie aber nicht unbedingt einfacher zu editieren oder gar interpretieren. Zum aktuellen Zeitpunkt würde ich diesen Teil des Proposals eher ausklammern wollen.
Ansonsten finde ich das Proposal eigentlich ganz vernünftig und kann mir auch gut vorstellen, dass man verschiedene Karten und Router in überschaubarem Zeitraum entsprechend anpassen kann.
Wobei jetzt eine Radkarte nicht unspezieller ist als eine LKW-Karte oder eine Wanderkarte. Evtl. weniger populär. Wanderkarten und Radkarten werden wahrscheinlich eher weniger davon profitieren, weil die Einschränkungen ja eher den Kraftverkehr betrifft. Ob halt die Höchstgeschwindigkeit an Schultagen 30 ist oder nicht ist für Radler und Fußgänger eher uninteressant. 
Wildwuchs befürchte ich da nicht groß. Klar wird es flexibel sein, aber diese Flexibilität wird sich in den Grenzen des opening_hours-Schema befinden. Klar ist, dass man mit einem Parser, der String=String vergleicht bei solchen Tags nicht weit kommt. Da muss der Parser dann mehr Intelligenz mitbringen. Aber die bräuchte er auch, wenn er die variablen Teile im Value auswerten müsste.
ja und?
Das betrifft doch nur die komplizierteren Situationen, die bisher sowieso nicht korrekt drin waren. Die waren zwar syntaxisch ok aber dennoch inhaltlich falsch.
Oder sie fehlten ganz.
Geschätzte 95% der Fälle sind eh trivial und werden mit den jetzigen Verfahren abgedeckt.
Der Vergleich mit opening_hours hinkt insofern, da dort kein einziger Fall trivial ist: “Mo-Fr 08:00-18:30” bietet schon genug Fehlermöglichkeiten, access=private dagegen fast keine (z.B. access=privat oder acess=private, …)
In anderen Worten: ich erwarte häufige Anfängerfehler in den Situationen, die bisher nicht erfasst werden konnten.
Gruss
Walter
p.s. unsere “Nachputzer” wollen ja auch was zu tun haben, seien es Mapper oder Bots 
Da die eine Gruppe die condition nicht im key haben möchte und die andere Hälfte dagegen ist, daß sie in den value kommt, ist es mal an der Zeit, eine Erweiterung der Struktur zu fordern: Dort, wo Konditionen nötig sind statt dem - Paar das Triplett -- verwenden.
Schöne Grüße,
Baßtölpel
Hallo Baßtölpel
Das würde aber einen kompletten Umbau der Datenstruktur und damit der API erfordern. Darüber hinaus müssten alle Editoren entsprechend angepasst werden. Ebenso müssten eine ganze Menge Tagging der neuen Variante angepasst werden.
Dort wo die Bedingung ein einfacher Wert ist, kann man mMn gut mit Key:Condition=Wert klar kommen. Aber wenn die Condition über bekannte Werte wie wet, hgv usw. hinausgeht, also selber aus variablen Werten besteht (Zeit, Gewicht, …), wird es unangenehm.
Der schon mehrfach geäußerte Vorschlag variable Bedingungen per Key:cond1/…/cond9=Wert plus cond1/… /cond9=Bedingung zu kodieren scheint mir sehr viel zielführender zu sein und deutlich besser in das Schema Schlüssel=Wert zu passen, als das rumgeeiere mit variablen Werten im Schlüssel oder zwei unterschiedlichen Werten (Bedingung und eigentlicher Wert) als Wert.
Edbert (EvanE)
Edbert, ich versteh das Problem nicht bzw. sehe für die Auswertung keinen Unterschied darin, ob da nun cond1 in der Bedingung steht und die dann woanders aufgelöst wird oder ob die Auflösung direkt darin steht. Auch ob das nun im key oder im value steht macht für die Auswertung keinen Unterschied. Beim Eintragen ist es auch egal…der normale Mapper gewöhnt sich an alles.
Für die Auswertung macht es keinen Unterschied, weil der String ja der gleiche ist. Da ist das mit cond1 eher noch umständlicher, weil man sich das ganze erst noch zusammensuchen muss. Vorallem ist es sehr gefährlich, wenn man filtert. Wer kommt schon auf die Idee, cond* in den Daten zu lassen, wenn er maxspeed auswerten möchte?
Das Key-Value-Paar ist deutlich einfacher, wenn man die Bedingungen in den Key packt. Andernfalls ist es sehr wahrscheinlich, dass man im value mehrere Bedingungs-Ketten hat. Da kommt dann erst Freude auf. Key=Bedingung11:Bedingung12:Value1;Bedingung21:Bedingung22:Value2
Das wird dann natürlich im Wiki beschrieben sein. Dort sollte jemand, der Auswertungen macht, unbedingt hineinsehen, erst recht wenn es maxspeed betrifft, wo man die ganzen Default- und impliziten maxpeeds je nach Land, Straßen- und Fahrzeugtyp berücksichtigen muss.
Ich sehe da einen elementaren Unterschied. Bisher ist es so, dass man im Schlüssel einfache Worte (schlimmstenfalls Abkürzungen) oder eine Hierarchie aus einfachen Worten stehen hat. Ein spezielles Parsing außer auf den Doppelpunkt als Hierarchie Trenner ist bisher also nicht notwendig.
Im Gegensatz dazu muss je nach Schlüssel der Wert ggfs. (z.B. bei opening_hours) aufwendig analysiert (geparst) werden.
Diesen Aufwand jetzt auch in dem Schlüssel einzuführen halte ich für keine gute Sache.
Ich habe mich an das eingeführte Schema wie bei highway=construction plus construction=Highway-Wert und vielen ähnlichen Konstrukten zur Verfeinerung von Angaben orientiert. Das ist bekannt, die Auswertung dafür muss nur erweitert werden.
Übrigens wird dein Beispiel dafür aufgelöst in:
cond11=Wert1
cond12=Wert2
cond21=Wert3
cond22=Wert4
Also keine Mehrfachwerte für einen Schlüssel.
Edbert (EvanE)
Hallo Edbert,
das ist mir klar.
Seit mehreren Jahren vegetiert hier ein wichtiges und gutes Proposal wegen formaler parsing-Probleme vor sich hin. Wenn die Probleme wirklich so bedeutend sind, wie die Ablehner behauptem, muß man eben auf tieferer Ebene etwas umgestalten. Eine Bedingung ist nun mal weder ein key noch ein value sondern etwas eigenständiges. Wenn man es also nicht schafft, die üblichen tools so zu erweitern, daß sich Bedingungen entweder im key oder im value als solche flexibel definieren lassen, dann muß eben die Datenstruktur geändert werden.
Baßtölpel
Aber mit dem cond*=* ändert sich am Parsen nichts im Vergleich zu dem Proposal.
Interessiert mich der basekey, muss ich auch variable cond* parsen. Die gehen ja nicht bei 1 los und müssen auch nicht direkt auf einander folgen. Dann suche ich mir die Bedeutung von der Bedingung heraus etc.
Das kann ich aber auch gleich machen in dem String des Keys machen.
Bsp:
maxspeed=80
maxspeed:motor_vehicle:wet=60
maxspeed:hgv:wet:(Mo-Fr 07:00-16:00)=30
maxspeed:hgv:(Mo-Fr 07:00-16:00)=50
wird zu:
maxspeed=80
maxspeed=cond1:cond2=60
maxspeed=cond3:cond2:cond4=30
maxspeed=cond3:cond4=50
cond1=motor_vehicle
cond2=wet
cond3=hgv
cond4=Mo-Fr 07:00-16:00
Naja, deswegen will ich ja schon eine Weile Unterstützung für baumförmige Wertzuordnungen in API 0.7 haben. 
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 (EvanE)
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.
Edbert (EvanE)
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.
Gruss
Walter
[1] http://www.postgresql.org/docs/9.1/static/hstore.html
p.s. wie sehen eigentlich Mapnik-Rules mit variablen Keys aus?
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.