access:conditional

Da war ich mir nicht sicher, ob PH dann richtig behandelt wird, deswegen hab ich es erst mal explizit dazu geschrieben. Hast du Beispiele, wo man sich das mal ansehen kann?

Graphhopper hat eine eingeschränkte Unterstützung bedingter Beschränkungen.

Im Wiki das vorletzte Beipiel: “Mo-Su,PH 15:00-03:00; easter -2 days off”
https://wiki.openstreetmap.org/wiki/DE:Key:opening_hours
(Das “PH” zählt im Prinzip auch nur zu den weekday-Selektoren)

Mit dem Eval-Tool kann man immer ganz gut prüfen (einfach die eigene Angabe bei “Wert für opening_hours” rein kopieren):
http://openingh.openstreetmap.de/evaluation_tool/

Bei deiner ursprünglichen Schreibweise wäre die Bedingung bei allen Feiertagen des Jahres erfüllt gewesen. Also auch außerhalb von Mai bis September.

Dann muss es so ausschauen:

access=no
bicycle:conditional=yes @ ...
foot:conditional=yes @ ...

Daneben müsste man überlegen, ob highway=service überhaupt korrekt ist.
Evtl wäre

highway=path
foot=designated
bicycle=designated

das Mittel der Wahl.

Das ist aber von der Beschilderung vor Ort abhängig! Daher möchte ich nochmal auf das Verkehrszeichentool verweisen: http://osmtools.de/traffic_signs/

Grüße

Denkt aber bitte an Folgendes: Wenn highway=path mit bicycle=designated und foot=designated eingetragen wird, dann müssen zeitliche Einschränkungen beim Zugang (zumindest für Fußgänger und Radfahrer) auch immer mit bicycle:conditional und foot:conditional angegeben werden und nicht mit access:conditional, denn ansonsten ziehen selbst Router, die eigentlich conditional restrictions auswerten können, beim Fußgänger-Routing zum Beispiel das foot=designated dem access:conditional=no @ (…) vor, weil foot die Fortbewegungsart genauer beschreibt als access(:conditional).

… hat doch hsimpson in seinem Beispiel genau so gemacht, und zwar schon vor dem Hinweis auf foot/bicycle=designated … oder verstehe ich gerade etwas nicht und du möchtest auf etwas anderes hinaus?

ich glaube, Lukas meint, dass die Router generell ein foot=designated hoher stellen als ein access:conditional=*, letzteres also in dem Falle nicht für Fußgänger auswerten.

Finde ich grenzwertig. Natürlich beschreibt ja designated auch ein Verkehrsschild, was dazu noch dem access=no wiederspricht, aber meiner Meinung nach sollten access-Tags immer als erste ausgelesen werden, dann die designated. Wenn ein Fuß-/Radweg wegen Bauarbeiten lange gesperrt ist, lasse ich trotzdem die designated-Werte dran, schon alleine um das danach nicht erneut erfassen zu müssen.

Grüße

Ja, hsimpson, das sehe ich grundsätzlich genauso und es war auch das, was ich meinte das hast du korrekt wiedergegeben. Es ist halt die Frage weil ich habe mich mal damit beschäftigt, wie ein Router die access-Werte genau auswerten soll. Ich meine im Prinzip ist es schon klar aber wenn man sich genauer damit beschäftigt, dann merkt man dass es schon viele unterschiedliche Fälle gibt bei denen sich die Frage stellt - was soll jetzt dem einen oder anderen vorangestellt werden in der Auswertung. Das wird halt kompliziert, wenn conditionals und nicht-conditionals aufeinandertreffen, die nicht den gleichen Fortbewegungsart-Key haben. Ich kann mir nicht so gut vorstellen, dass die Hierarchie der Auswertung sich nach den Values (no, designated etc. ) richten soll…
Ich kannte es halt so, dass je spezifischer die angegebene Fortbewegungsart, desto eher wird es berücksichtigt und vom Angegebenen wird halt immer das berücksichtigt, was die Fortbewegungsart am genauesten beschreibt. Das gilt für mich auch dann, wenn conditionals mit nicht-conditionals zusammenspielen.

Aber vielleicht liege ich halt bei genau dieser Annahme falsch. Wenn conditionals ausgewertet werden, dann kann man beim Router auch sagen, er soll diese Auswertung komplett von der Auswertung der nicht-conditionals trennen und bei der Auswertung der conditionals nicht darauf achten, welche nicht-conditional-Werte da sind.
Das führt aber dann auch wieder zu Problemen.
Unrealistischer Fall, aber egal, nur Beispiel:
Ein Weg, der von Mofas immer benutzt werden darf aber von anderen Fahrzeugen nur nachts. Tagging:
mofa = yes
vehicle:conditional = no @ (05:00-22:00)
vehicle steht über mofa, d. h. wenn der Router das conditional auswertet ohne auf die nicht-conditionals zu achten, dann werden Mofas zwischen 5 und 20 Uhr da nicht hergeleitet, auch wenn sie dann da her dürften. Man kann bei solch einer Auswertung mit mofa=* die vom vehicle:conditional definierte Beschränkung nicht mehr für Mofas ausnehmen. Dasselbe ist es bei access:conditional und foot. Wenn du eine Straße z. B. nachts für alle außer für Fußgänger sperren willst, dann kannst du das mit einem reinen access:conditional und einem foot=yes nicht machen. Da weiß ich jetzt nicht, ob das so sein soll. Ich möchte mir ehrlich gesagt jetzt nicht unbedingt anmaßen, das zu beurteilen. Müsste man klären. Zugegeben es ist auch super kompliziert. Sich damit zu beschäftigen führt immer wieder zu Fällen, in denen es irgendwie Probleme oder Unstimmigkeiten gibt.

Und dann noch etwas zu deinem Beispiel mit dem länger im Bau befindlichen Fuß-/Radweg: Ich will ja nicht kleinlich sein aber das ist halt schon wieder so eine Diskussionssache. Der schlaue Router schaut erst nach dem highway-Wert und routet natürlich nicht über highway=construction, ganz klar. Aber der nicht so schlaue Router nimmt den Weg, weil es ist ein highway und noch dazu gilt foot=designated, d. h. der Weg ist sogar vorgesehen für Fußgänger. Ich dachte früher auch, access würde foot und anderes überschreiben, aber so ist es halt eben nicht. Ich weiß dass das manchmal schwierig ist aber bei jedem Weg kann noch so viel access=no dranstehen und das kann auch als erstes ausgewertet werden, aber ein foot=designated überschreibt für Fußgänger den Zugang immer. (Auch) unabhängig vom highway-Tag.

Schwieriges Thema, da stimme ich dir zu.

Dein Mofa-Problem könnte man allerdings lösen:

vehicle=no
vehicle:conditional=yes @ (22:00 - 05:00)
mofa=yes

Das ist natürlich jetzt eine Einzelfalllösung, damit will ich nicht sagen, dass alles derart gelöst werden kann. Dafür bin ich schon alleine bei weitem nicht tief genug in dem Thema drin.

Edit: Kleine Erläuterung dazu:

Das mofa=yes überschreibt schon das vehicle=no, damit muss der conditional-Wert hier überhaupt nicht mehr angewendet werden.

Grüße

Generell kann man das Thema warscheinlich am besten so runter brechen:

• Es gibt verschiedene Stufen: access > vehicle > motor_vehicle > mofa

• Kleinere Stufen überschreiben immer die Werte für Größere Stufen, z.B. bei

vehicle=no
mofa=yes

überschreibt das mofa=yes für die Nutzungsart Mofa das vehicle=no

• Das gilt auch für conditional-Werte!

• Meiner Meinung nach sollten dann erst ganz unten diejenigen Werte kommen, die ein access-Tag nur implizieren, wie

motorway=yes
motorroad=yes
*=designated
etc.

Diese implizierten Werte sollten konsequent allen access-Werten untergeordnet und erst dann berücksichtigt werden, wenn es für die gefragte Nutzungsart keinen eigenen access-Wert gibt.

Grüße

Das hast du gut zusammengefasst! Vielen Dank für deine Beiträge, das hat mir wirklich weitergeholfen.

Keine Ursache

Erstmal vielen Dank für die hilfreichen Antworten!
Ich hab mich, so gut es ging, noch mal schlau gemacht über die Situation.
Die Brücke über das Sperrwerk wird erst mal grundsätzlich nur im Notfall oder für Servicearbeiten runter geklappt. Sie ist also für jeden öffentlichen Verkehr gesperrt. Weil aber Fußgänger und Radfahrer nix wiegen und demzufolge auch nix kaputt machen, dürfen die für touristische Zwecke ab und zu mal die Brücke benutzen.
Deswegen werde ich folgende Variante taggen:
highway=service
service=emergency_access
access=no
bicycle:conditional=yes @ (May-Sep: Sa,Su,PH 10:00-12:00,17:00-19:00)
foot:conditional=yes @ (May-Sep: Sa,Su,PH 10:00-12:00,17:00-19:00)

Sieht gut aus.

Moin,

na ja - in Post #11 hat hsimpson noch genau das Gegenteil geschrieben:
Da soll(te) das generelle access:= den ‘kleineren’ Wert foot=designated übersteuern …
Mich hat er daher eher verwirrt.

Grüße, Georg

Nein, das hat hsimpson nicht geschrieben. Er schrieb, access=* sollte zuerst ausgelesen werden und dann die kleineren. Wobei die später ausgelesenen Werte den zuerst ausgelesenen überdecken.

–ks

Ließ seinen Post #11 bitte noch einmal.
Insbesondere die ersten beiden Sätze sowie den letzten Satz.

Was ich dazu noch zu sagen hätte ist:
hsimpson hat (im Prinzip ja durchaus richtig) u. a. festgestellt, dass ein “designated” ein Zugangstag (Zugang gestattet und sogar für diese Verkehrsart vorgesehen) eigentlich ja nur implizieren, nicht explizit beschreiben, würde. Da “designsted” ja für ein blaues Schild steht. So wie ich es verstanden habe hat er dann aber einen Zusammenhang mit der Auslesung der access-Werte und deren Reihenfolge der Auslesung hergestellt, aber die hat ja sich nicht nach dem Value zu richten. Das sollte schon klargestellt werden, dass ein foot=* nicht von einem access=private zum Beispiel überschrieben wird, wenn foot=designated dran steht, wenn foot=yes dransteht dann aber wird es nicht vom access-Wert überschrieben oder so in der Art. designated steht schon für eine konkrete Zugangsberechtigung. Das ist ganz klar. Ursprünglich ging es ja darum, ob bei Mischung von conditional und nicht-conditional ein access mit conditional für Fußgänger ausgewertet wird, wenn ein foot=* ohne conditional da ist.

…das gleiche “Problem” besteht auf der anderen Elbeseite beim Krückau und Pinnau-Sperrwerk ebenfalls. Beim Pinnausperrwerk (https://www.openstreetmap.org/way/144073755) sind generelle Öffnungszeiten benannt, beim Krückausperrwerk (https://www.openstreetmap.org/node/1432976039) nicht…
Vielleicht können diese beiden anderen Sperrwerke in diesem Zuge direkt mit getaggt werden…