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.
was das ist in dem Sinne von “was es bedeutet”, ist mir total egal. Es passt zu 100% in die etablierte Syntax vom Subtagging rein, und das ist gut so.
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.
gruss
walter
für mich: eod
maxspeed:wet=80
IF wet=yes THEN maxspeed=80
passt → Bedingung
addr:city=Schlangenbad
IF city=yes THEN addr=Schlangenbad
wäre Blödsinn → keine Bedingung
Moin,
Leute, es macht überhaupt keinen Sinn, wenn Ihr mit
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.
Gruß
Georg
Das ja, ändern wir die Bedingung von Nässe auf Uhrzeit ab, sieht es aber schon anders aus:
maxspeed:hgv:(22:00-08:00)=50
ä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.
Gerhard
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.