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?
Gruß,
Mondschein
Abstimmung ist beendet?
könnte sein:
+8 / + 2 halbe / -17 → 9/17
danach gescheitert? http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags
Gruss
walter
Also ich versteh’s net…
Ob ein bisschen variabel oder komplett variabel macht nicht den Unterschied. Entweder kommt eine Software mit variablen Keys zurecht oder nicht. Wenn nicht, ist es auch egal, wie variabel er ist.
was gehen würde, wäre maxspeed=80 + maxspeed:conditional=langer String mit Conditions bspw conditional=[wet=80];[hgv:wet=50];[(22:00-06:00) =50]
man hättest das “normale” Maxspeed da wo es immer ist und würde alle komplizierten Bedingungen in den Value auslagern. Über [] () , und ; Trenner müsste man sich halt noch streiten.
@SunCobalt
Ja, sowas schwebte mir auch schon vor:
http://www.mail-archive.com/talk-de@openstreetmap.org/msg92031.html
Der Wunsch vieler (ob ich ihn teile oder nicht) war halt, keine variablen Keys. Du hast variable Keys, die sind zwar nur ein wenig variabel, aber sie sind es.
Moin,
im Prinzip stimme ich Dir zu - aber ich halte nicht viel von “Wahrscheinlichkeitswerten als lautere Wahrheit”.
Wenn ein maxspeed von Bedingungen abhängt, dann bringt es nichts, einen vermeintlichen, geschätzten, per Wahrscheinlichkeitsrechnung bestimmten Wert im (Haupt-)Key abzulegen.
Der ist dann gemäß Murphy grundsätzlich falsch, wenn es drauf an kommt - trotz aller Beteuerungen der Wahrscheinlichkeitsrechnung.
Dann kann man gleich den Key “maxspeed” mit den Bedingungswerten verwenden.
Es ist doch egal, ob
Software wie Fahrer müssen entweder den ‘korrekten’ Wert zur Verfügung haben oder eh nach bestem Gewissen verfahren.
Letzteres müssen sie zwar sowieso meist - aber man sollte ihnen nicht auch noch wissentlich etwas vorgaukeln.
Gruß
Georg
Ein ähnlicher Vorschlag währe folgender:
maxspeed=50
maxspeed:time=30;Mo-Fr 8:00-19:00;Sa 9:00-15:00
bzw. die “sichere” Beschränkung auf dein normalen tag:
maxspeed=30
maxspeed:time=50;Mo-Fr 19:00-08:00;Sa 15:00-09:00
“time” kann man auch “opening_hours” ersetzen. Der value setzt sich aus dem maxspeed-Key getrennt von dem ersten “;” (oder ein anderer Trenner, z.B. “|”) und dem “opening_hours”-Ausdruck zusammen.
ODER (mMn sogar besser:)
Wenn wir 2 oder mehr values haben und…
keinen Key im Value haben wollen
keine verknüpften Tags ala maxspeed:cond1=50 + cond1=08:00-19:00
nicht das derzeitige key-value Prinzip verändern wollen
way: maxspeed=50
member: [der way mit maxspeed=50]
relation:
type=restriction
restriction=maxspeed
maxspeed=30
time=Mo-Fr 8:00-19:00;Sa 9:00-15:00
…
Man kann sogar die Richtung mit forward/backward als Rolle angeben (wie bei den Routen-Relationen, wird dann auch von JOSM erkannt und mitgeändert, wenn der Weg gedreht wird).
so ähnlich gefunden unter: http://wiki.openstreetmap.org/wiki/Key:restriction:hgv#Time_Based_Speed_Limits
Klappt sogar für die deutsche Maut:
relation:
type=restriction
restriction=toll
hgv=yes
minweight=16
toll=yes
fee=*
time=Mo-Fr 8:00-19:00;Sa 9:00-15:00
Hallo MasiMaster,
deine Vorschläge bringen auch keine wirkliche Verbesserung. Bei " 30 für LKW zwischen 22 und 6" scheitert es schon, weil es zwei Bedingungen gibt.
Relationen wäre eine Möglichkeit…wobei ich noch nicht so recht dran glaube, dass das für viel Begeisterung sorgt.
Ja, den Vorschlag gab es auch mal…jetzt stell dir das aber in einem aktuellem Editor an der Stelle vor, wo man den Tag eingibt. Das kann man kaum editieren und auf Fehler überprüfen etc.
Wie gesagt, der Vorschlag ist im Prinzip der gleiche wie der von chris66, nur dass man nicht 3 values hat, die in Klammern geschachtelt sind, sondern nur 2, welche durch ein Zeichen getrennt sind.
maxspeed:hgv:wet:time=50;Mo-Fr 19:00-08:00
Finde die Lösung aber nicht so elegant, da man keine Vorgabe der Reihenfolge hat: maxspeed:hgv:wet:time oder maxspeed:wet:hgv:time.
Also abgelehnt!
Klar sind Relationen ein wenig komplizierter zu verstehen, als einzelne Tags an Wegen. Aber Relationen haben nunmal ihre Berechtigungen, sei es bei Abbiegebeschränkungen, Multipolygonen oder Routen, bei denen es ohne Relationen schwierig ist sie abzubilden. Genauso sehe ich das bei den Einschränkungen/Beschränkungen. Mit Relation elegant & einfach 
Bedingungen in Relationen zu packen hab ich auch schon mal vorgeschlagen. (Ich hab bei dem Thema wirklich schon so ziemlich alles versucht. ;))
http://wiki.openstreetmap.org/wiki/Proposed_features/Conditions_for_restriction_relations
Wurde natürlich abgelehnt, wie bekanntlich jeder Vorschlag zu Bedingungen bis zum heutigen Tage. Und das, obwohl es da um Abbiegebeschränkungen ging, wo ja nur die ohnehin vorhandenen Relationen mit zusätzlichen Tags versehen worden wären.
Das Proposal ist gut, habe leider die Abstrimmung nicht mitbekommen.
Der Vorschlag 2 von MasiMaster berücksichtigt nicht die Tatsache, das die Keys prinzipiell ja alle unabhängig voneinander sind, und ausgelagerte separate variable Keys (existiert cond1234=* noch und wurde vielleicht cond1233=* nur durch einen Fehler davor vergesssen?) sind es ja trotzdem.
Auf der Tagging-Liste hat jemand einen neuen Proposal-Versuch angekündigt: http://wiki.openstreetmap.org/wiki/Proposed_features/Conditional_restrictions. Variable Bedingungen sind dabei im Wert. Klingt in etwa wie das, was SunCobalt in Post http://forum.openstreetmap.org/viewtopic.php?pid=262462#p262462 erwähnt.
Ach, dann hatte ich da doch abgestimmt, aber weil das Proposal mir nicht perfekt genug war (ja, Verrkwehrszeichen sollte man imho auch extra also solche mappen), habe ich es damals abgelehnt, wußte ja nicht, was noch so danach an Vorschlagen kommen wird…
Ja, dafür möchte ich auch noch mal Werbung machen, damit das nicht überlesen wird.
Ich halte es für eine sehr gute Lösung und den logischen nächsten Schritt nach der Reaktion auf Extended Conditions. Es gibt dabei eine definierte Liste von Schlüsseln, die keinerlei variable Anteile enthalten. Damit dürfte der Hauptkritikpunkt an anderen Vorschlägen behoben sein.
Die Idee ist dieselbe, die wir auch hier im Forum schon diskutiert haben, z.B. in dem zitierten Post: Die möglichen Fälle werden zusammen mit den Bedingungen, unter denen sie gelten, in den Wert des Tags geschrieben. Das sieht also so aus:
maxspeed = 50
maxspeed:conditional = 30:(Mo-Fr 07:00-17:00)
Mehrere Wert-Bedingungs-Paare werden durch Semikolon getrennt, die Bedingungen lassen sich über “AND” verknüpfen.
Eine Besonderheit ist, dass es einige “einfache” Bedingungen im Schlüssel belässt, nämlich Fahrzeugtypen und forward/backward. Höchstgeschwindigkeiten für hgv sähen also wie gehabt so aus:
maxspeed = 100
maxspeed:hgv = 80
Das wirkt auf den ersten Blick inkonsequent, hat aber praktische Vorteile. Unter anderem …
Es ist kompatibel mit bestehenden Praktiken, beispielsweise nutzen wir ja auch beim access-Tagging millionenfach Fahrzeugtypen im Schlüssel (bicycle=yes etc.)
Es sorgt dafür, dass die Werte nicht zu lang werden, was sowohl für die Lesbarkeit als auch aus technischen Gründen (255-Zeichen-Limit) sinnvoll ist.
Editoren können weiterhin beim Drehen von Ways darauf achten, ob forward/backward genutzt werden, ohne sämtliche anderen Bedingungen verstehen zu müssen.
Die Syntax ist etwas anders als unsere bisherigen Gedankenspiele. Wenn jemand das Konzept gut findet, aber lieber ein paar andere Sonderzeichen nutzen würde, schlage ich einen Kommentar auf der Diskussionsseite vor.
gefällt mir auch. Evtl sollte er da noch ein komplexes Beispiel mit aufnehmen damit klarer wird, dass eine Verkettung erlaubt ist, also bspw
maxspeed=120
maxspeed:conditional=100:(Mo-Fr 07:00-17:00);80:(17:00-20:00);60:wet
jau, das ist es!
glaube ich zumindest auf den ersten Blick - aber ich will das Kind nicht totschlagen, da es wirklich einen lebensfähigen Eindruck macht.
Gruss
walter