Ich fänds gut, das weiter zu verfolgen.
Eckhart Wörner scheint auch gerade vorzuhaben, das Extended-Conditions-Proposal wiederzubeleben und hat gestern einen großen Thread auf Tagging losgetreten: http://lists.openstreetmap.org/pipermail/tagging/2012-June/010542.html
Ich lese es gerade…
Genau deswegen mag ich keine Proposals. 50 Leute, 50 Meinungen und jede Menge Grundsatzdiskussionen, Spezialfälle, etc. Ich wollte nur ein paar gängige Fälle vereinheitlichen, nicht etwas neues erfinden. Naja, ich werds mir heute Abend nochmal genauer durchlesen
wie prophezeit:
leider sehr theorielastig die diskussion auf der mailinglist. ich würde mir immer noch wünschen, dass sich programmierer von routingprogrammen mal zu wort melden und die proposals von deren standpunkt aus bewerten.
Für den Router (ich arbeite mit mkgmap) ist die Syntax vollkommen Schnuppe. Da reicht mir schon ein 1=2, wenn dokumentiert ist, dass dies bedeutet, dass bei Nässe nur 80 erlaubt ist, um es mal auf die Spitze zu treiben. Wichtig ist, dass es etwas einheitliches gibt und ich neben 1=2 nicht auch noch Taginfo etc. durchstöbern muss um weitere Tags zu finden, die sich Mapper ausgedacht haben.
ich habe das Proposal wieder gelöscht. Mit solchen Unsymphaten wie Eckhart will ich nichts zu tun haben. @Tordanik: Ich habe mich vorhin auf der ML aus Versehen als Autor Deines alten Proposals bezeichnet, statt des auf Deinem aufbauenden, leicht erweitertem neuen Proposals. Bin mit den Bezeichungen durcheinander bekommen. Tut mir leid.
Das Proposal von Tordanik steht aktuell zur Abstimmung…
http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags
Na ja, zumindest hat er sogar als erster approved
…
und 3 Stunden später angelehnt, ohne das Approval zu löschen.
scheint noch nicht einmal für sich zu wissen, was er wirklich will 
mal sehen, ob er es merkt.
Gruss
Walter
Er hat nicht nur als erster approved, er hat das Voting gestartet. Ich hab damit nichts zu tun.
Das ist nur ein Kommentar zu Pierens Ablehnung.
JO, bin leider etwas durcheinander gekommen. Heute irgendwie nicht mein Tag.
er muss damit durchkommen, da er schon eine Weile Tags in dieses Schema ändert. Ich weiß noch nicht was ich mache. Einerseits könnten meiner Meinung nach noch ein paar Verbesserungen rein aber mit dem … kann man ja nicht reden. Anderseits wäre das schonmal ein großer Schritt vorwärts. Der Pierren kommt mit tag, value und condition durcheinander. Das hatte ich extra erläutert, da es nicht auf den ersten Blick ersichtlich ist, was wo hin gehört wenn man nicht lange drüber nachdenkt. Ist ja noch ein bissl Zeit und wenns auf der Kippe steht, stimme ich zu
Warten wir’s mal ab.
Womit ich so meine Probleme habe, sind die variablen keys (z.B access:(weigth>3.5)=* oder auch access:weigth>3.5 in Tordaniks Vorschlag). Damit kann ich mich überhaupt nicht anfreunden und werde daher wohl ablehnen. Das Blöde ist, dass ich selber auch keine passable Lösung habe 
Gruss
Walter
Muß ich leider ablehnen, siehe Pieren, weil wenn sollte der Key relativ fest/konstant sein und dann sollte es imo maximal einen Subkey (z.B. :hgv=, etc.) geben, weil sonst wird das einfach zu variabel um das noch überhaupt sinnvoll automatisch auswerten zu können.
Beim Key access:= ist halt nur yes, destination,… ein gültiger Value. Das 5.5 ist die Condition. Ich hatte es in maxweight:destination=5.5 geändert. Hier passt dann der Value 5.5 zu dem Key maxweight:=
Aber ganz sauber empfand ich es auch nicht. U.A. da es sich manchmal nicht vermeiden lässt, scheinbare Values als Condition in den Key zu schieben. Bsp: bicycle :(07:00-18:00)=no. Der passende Basekey zu 07:00-18:00 wäre opening_hours. Will man nun die Zeiten in den Value schieben, muss man den passenden Basekey benutzen. Das wäre dann opening_hours:bicycle= 07:00-18:00
Auch unschön
Außerdem kann es auch andere Bedingungen geben, die mehrere Values als Bedingung haben. Bspw. maxspeed:(7:00-16:00)=30. Statt der zeitlichen Beschränkung kann es natürlich auch eine Beschränkung übers Gewicht geben. Bspw. maxspeed:(weight>20)=30
Ach so, das erklärt einiges. Auch warum er im Voting auf alle Ablehnungen antwortet und dabei hartnäckig auf seiner Meinung beharrt.
Ich verstehe nicht, warum so viele was gegen zusammengesetzte Keys haben. Im Zeitalter von regular expressions sind die genauso leicht auswertbar wie fixe Keys. Vielleicht sind die Ablehner keine Programmierer.
Was ich am Proposal aber gar nicht gut finde, sind die Klammerausdrücke. Ich hab das im Voting schon erklärt, aber dort ist nicht der richtige Platz zum Diskutieren, daher spreche ich das hier nochmals an. Laut Eckhart sollen die Klammern die Lesbarkeit erhöhen; ich finde aber, dass genau das Gegenteil bewirkt wird. Je länger, desto schwerer lesbar. Außer wenn man Leerzeichen (nach den Doppelpunkten) einfügt - das könnte man andenken. Anwendungen tun sowieso gut daran, Leerzeichen nach anderen Trennzeichen zu akzeptieren.
So oder so - die beste Lesbarkeit nützt nichts, wenn beim Erfassen Fehler passieren. Und die sind mit den Klammern vorprogrammiert. Die Klammern müssen im Normalfall händisch eingegeben werden. Da wird mal auf die rechte Klammer vergessen, mal wird die falsche Taste erwischt… Ein Graus! Darum bitte wenn möglich die Syntax einfach halten, d.h. ohne Klammern.
Aber auch ohne Klammern sehe ich in der vorgeschlagenenen Syntax Probleme:
1.) Vergleichsoperatoren: Wenn > und < erlaubt sind, werden Leute auch >= und <= eingeben. Ich glaube, ihr werdet mehrheitlich mit mir übereinstimmen, dass ein “=” im Key problematisch ist.
2.) Zeitangaben: Die sollten mit irgendeinem Keyword beginnen, damit sie von den anderen conditions sicher unterschieden werden können. Evtl. könnte man hier doch auf Klammern - () oder - zurückgreifen. Die Gefahr bei den Zeitangaben ist, dass ihre Syntax ziemlich komplex ist und vielleicht sogar noch erweitert werden wird. Wenn dort Zeichen wie :=() dazukommen, gibts in den Keys Probleme. Dann müssten diese Syntaxelemente in Keys verboten werden, womit das Vorhaben, einfach auf die opening-hours-Syntax verweisen zu können, fehlgeschlagen ist.
Wie sich das am besten lösen lässt, weiß ich nicht. Vielleicht komplexere Syntax in andere Tags auslagern, z.B.:
maxspeed:forward:cond1 = 70
cond1:hours = Mo-Su 08:00-18:00; Apr 10-15 off; Jun 08:00-14:00; Aug off; Dec 25 off
Ist für dieses Proposal eine benutzerfreundliche Pflege in JOSM geplant? Also ein Klicki-Bunti-Assistent, mit dem man sich die entsprechenden Regeln zusammenklicken kann, ohne sich mit der Syntax auseinandersetzen zu müssen. Ich denke da an nach einer Woche fehlerfrei aus dem Gedächtnis anwenden. Gleiches gilt für die Prüfung auf zulässige Werte vor dem Hochladen.
Prinzipiell ist die Idee nicht schlecht, fühlt sich aber etwas over-engineered an. Da könnte man ja auch gleich eine Formel im Excel-Style in den Wert packen: **maxspeed=if(wet;80;100) ** - wobei damit die Verarbeitung schon extrem aufwändig wird.
mach da noch maxspeed:if(wet;80;100) raus und ich stimme jederzeit zu.
Ich hatte schon länger -na ja, seit 1-2Tagen - daran gedacht, dass da “richtige” Formeln reinmüssten. Etwas, was eine formale Syntax hat und durch einen kleinen Parser verarbeitet werden kann. Kommt ja fast schon an die Lösung von Thomas (SunCobalt) ran.
gruss
walter
p.s. der hier kann sowas: http://ewbi.blogs.com/develops/2004/12/excel_formula_p.html (allerdings nur mit = ). Einfach mal maxspeed=if(wet;80;100) eingeben.
Und was kommt dann bei dir noch in den Value? Außerdem, bevor man so ein komisches Excel-Konstrukt nutzt, wäre doch der klassische ternäre Operator wie er in jeder zweiten Programmiersprache aussieht aussagekräftiger: “maxspeed=wet?80:100” und kommt auch ohne “;” aus, also keine Gefahr, dass jemand aus Versehen den Tag splittet, ohne das zu wollen.
Das mit dem If ist ja erstmal nicht schlecht und bei einer Einschränkung für den Key auch noch von normalen Menschen verständlich. Bei komplexeren Fällen mit mehreren Einschränungen für ein Basekey steigen dann aber alle nicht-Programmierer aus.