Streiten mit Dir hat ja eh keinen Sinn. Nur soviel, maxspeed:wet= ist etabliert und im Proposal steht, "Backward compatible. Doesn’t break any established tagging schemes. "
Ob Du nun behauptest etwas sei erlaubt oder nicht, ist vollkommen irrelevant. Im Proposal steht, es ist erlaubt (und zeigt eine zusätzliche Möglichkeit des taggens) und wir stimmen hier über das Proposal ab, nicht über Deine Meinung
War das jetzt Dein “simple challenge” oder kommt da noch was?
Ist es wirklich so schwer, ein Proposal zu lesen? “Backward compatible. Doesn’t break any established tagging schemes.” ist eine (unbegründete) Behauptung, dass das Schema abwärtskompatibel ist, und nicht Teil der Spezifikation.
Vielleicht hast du übersehen, dass ich dein “und so weiter” als falsch bezeichnet habe?
Das Proposal erlaubt genau zwei Dinge im Key: Fahrzeugtyp und forward/backward.
maxspeed:wet gehört zum mit dem vorliegenden Proposal konkurrierenden Proposal-Paar “Conditions for access tags” und “Extended conditions for access tags”. Mit einer Stimme für das vorliegende Proposal entscheidest du dich gegen diese Lösung.
Sehe ich anders. Das Proposal ist eine Erweiterung. Nur für diese Erweiterung (*:conditional) erlaubt es kein wet mehr im Key (bspw. maxspeed:wet:conditional=). Ich kann nicht rauslesen, dass damit bestehende access Restrictions wie maxspeed:wet umformuliert werden müssen, sondern halte mich an den Satz "Doesn’t break any established tagging schemes"
Sich ausgerechnet an den Satz zu halten, der sehr offen für subjektive Interpretation ist, ist vielleicht nicht die beste Wahl. 
Das Proposal nennt “maxspeed:conditional=80 @ wet” ausdrücklich als Tagging-Beispiel - so weit besteht auch kein Interpretationsspielraum. Auch wenn das nicht ausschließt, dass der Proposal-Autor “maxspeed:wet” als etablierte gleichwertige Alternative betrachtet, erscheint es doch nicht besonders sinnvoll, zwei komplett verschiedene Tagging-Methoden für “Höchstgeschwindigkeit bei Nässe” zu haben.
Insofern ersetzt das Proposal kein etabliertes Tagging, aber es macht die Einführung anderer Tagging-Schemata überflüssig, die genau dieselben Situationen beschreiben.
Der Unterschied zwischen unseren Auffassungen kommt wohl auch daher, dass ich maxspeed:wet nicht als etabliert bezeichnen würde: Keine mir bekannte Nutzung in Anwendungen, gerade einmal 500 Verwendungen in der Datenbank - und außerhalb Deutschlands fast völlig ungenutzt.
Echt jezt? In diesem Fall passt mir dieses proposal doch nicht und habe mich nun doch zur Stimmabgabe entschieden.
Das ist gut möglich. Efred hat es in seiner Ablehnung explizit als Grund genannt. Jetzt kann er ja Farbe bekennen. Wobei ich meine Zustimmung/Ablehnung jetzt nicht unbedingt an der Existenz von maxspeed:wet festmachen würde. Ich kann auch mit maxspeed:conditional=80 @ wet leben, finde maxspeed:wet aber besser. Andererseits bekommen wir mit variablen Keys ja keine Mehrheit hin. Insofern ist ein Fortschritt mit kleinen Haken wesentlich besser als der Status Quo mit vielen ungelösten Problemen.
Mir persönlich ist es letztendlich egal, welches der beiden Proposals sich durchsetzt. Ich persönlich möchte nur endlich eine dokumentierte Möglichkeit haben. Bei dem jetzt zur Abstimmung stehenden Proposal sehe ich wesentlich bessere Chancen da es keine von der Mehrheit abgelehnten variablen Keys nutzt…Muss man nicht so sehen, zugegeben. Man kann auch warten (vielleicht vergeblich - keine Ahnung) bis die Mehrheit variable Keys akzeptiert, oder sich mal ein Proposal findet, das alle zufrieden stellt. Da glaub ich nur nicht dran
Ich auch nicht. Aber es diente mir nur gerade als Beispiel (darum p.e.). Und wenn solche tags (ich denke, da würde es sicher noch andere beispiele geben), nicht mehr gültig sind, finde ich das überhaupt nicht o.k. Vorallem da maxspeed:wet=* auch für Gelegenheitsmapper einfach zu taggen ist, hingegen mit dem neuen Taggingschema doch unnötig verkompliziert wird.
das liegt vielleicht daran, dass kein Navi einen Regensensor hat und somit dieses tag nicht ausgewertet werden muss. Aber zukünftig könnte es schon solche Software geben (die womöglich die Wetterinformationen von accuweather oder so abruft) und aufgrund dessen solche maxspeed-infos auch berücksichtigen kann. Von daher, egal wie die Abstimmung schlussendlich ausgehen wird, muss es einheitlich werden - also ggf das alte tag maxspeed:wet=* ersetzt werden (evtl. per bot) durch maxspeed:conditional=* @ wet
Welches Proposal meinst du?
Es gibt da schon noch ein paar Sachen (Key / Häufigkeit)
maxspeed:seasonal:winter 1614
maxspeed:wet 588
maxspeed:towing 555
maxspeed:children_present 447
maxspeed:bicycle 266
maxspeed:winter 233
maxspeed:summer 229
Wobei man hier auch wieder sieht, wie dringend ein Schema her muss…zwei Versionen für Maxspeed im Winter.
Dann wäre aber seine Aussage eindeutig falsch, wenn ich nicht völlig auf der Leitung stehe.
Key:
http://wiki.openstreetmap.org/wiki/Proposed_features/Conditional_restrictions#Key
Examples:
http://wiki.openstreetmap.org/wiki/Proposed_features/Conditional_restrictions#Examples
Es sind also im Key z.B. auch oneway, maxspeed, overtaking und maxlength erlaubt.
Das sind weder Fahrzeugtypen, noch forward/backward.
Oder verstehe ich etwas falsch?
Gruß,
Mondschein
Tordanik hat sich nicht genau ausgedrückt, es ging um den Subkey (d.h. alles ab dem ersten “:”).