You are not logged in.
- Topics: Active | Unanswered
Announcement
Pages: 1
#1 2018-02-28 14:16:28
- mbuege
- Member
- Registered: 2008-06-30
- Posts: 13
access:conditional
Zugegebenermaßen ist es schon recht lange her, dass ich mit solchen Sachen auseinandersetzen musste, aber ich möchte das Problem auch nicht ungelöst lassen.
Man sehe es mir nach, wenn ich eventuell schon vorhandene Diskussionen oder gar Lösungen zum Thema übersehen habe, sollte es welche geben, bin ich für jeden Hinweis dankbar.
Konkret geht es erst mal um dieses Objekt.
Wie angegeben kann man hier von Mai bis September am Samstag, Sonntag und an Feiertagen von 10:00-12:00 und17:00-19:00 Uhr mit dem Rad drüber. Also fast nie. ![]()
Trotzdem routet z.B. BRouter da lustig drüber, was bei Orts.- und OSM-Unkundigen zu Verdruss führen kann. Ich weiß, das machen quasi alle Router so, weil Tags zu zeitlichen Einschränkungen schlicht nicht ausgewertet werden. Mir geht es auch erst mal um den allgemeinen Umgang mit solchen Objekten und das empfohlene Tagging.
Ich würde den Access-Tag also folgendermaßen ändern.
access:conditional=yes @ (May-Sep Sa,So 10:00-12:00,17:00-19:00; PH 10:00-12:00,17:00-19:00)
Einwände? Empfehlungen? Vorschläge?
Offline
#2 2018-02-28 14:31:45
- hsimpson
- Member
- Registered: 2015-07-21
- Posts: 675
Re: access:conditional
Hi!
Generell: access=limited hours ist kein Standartwert und wird daher von den Routern nicht ausgelesen.
Mit den Zeitlichen Einschränkungen ist das so ne Sache.
Möglich sind access=yes + access:conditional=no @ ... oder aber access=no + access:conditional=yes @ ...
Technisch gesehen ist das ganze redundant, da aber eig kein Router access:conditional ausliest, sollte man für access=* den Wert wählen, der am häufigsten eintritt. Also würde ich hier hier erstmal access=no setzen.
Dann noch ein paar Zusatzfragen:
Der Weg ist außer an den angegebenen Zeiten komplett gesperrt für alle Benutzungsarten (also auch Fahrzeuge, Fußgänger, etc.)? Nur dann ist access=no korrekt!
Andernfalls bitte statt access=* spezifischere Werte wählen. Diese können hier nachgeschlagen werden: https://wiki.openstreetmap.org/wiki/DE: … ehrsmittel
Zeichen 250 impliziert z.B. kein access=no, sodern ein vehicle=no: https://wiki.openstreetmap.org/wiki/DE:Key:vehicle
Dieses Tool ist dafür sehr hilfreich: http://osmtools.de/traffic_signs/
Grüße
Fragen zu PTv2? Vlt mal in diese Übersicht schauen?
Offline
#3 2018-02-28 14:43:23
- milet
- Member

- Registered: 2017-07-13
- Posts: 292
Re: access:conditional
Nach Opening-Hours-Syntax müsste es (May-Sep: Sa,Su,PH 10:00-12:00,17:00-19:00) lauten.
Offline
#4 2018-02-28 15:03:51
- mbuege
- Member
- Registered: 2008-06-30
- Posts: 13
Re: access:conditional
Dann noch ein paar Zusatzfragen:
Der Weg ist außer an den angegebenen Zeiten komplett gesperrt für alle Benutzungsarten (also auch Fahrzeuge, Fußgänger, etc.)? Nur dann ist access=no korrekt!
Der Weg ist eigentlich eine Brücke über ein Sperrwerk und ist außer zu den angegebenen Zeiten hochgeklappt. Wird die Brücke runter geklappt dürfen nur Radfahrer und Fußgänger passieren.
https://de.wikipedia.org/wiki/Sperrwerk_Wischhafen
Offline
#5 2018-02-28 15:13:01
- mbuege
- Member
- Registered: 2008-06-30
- Posts: 13
Re: access:conditional
Nach Opening-Hours-Syntax müsste es (May-Sep: Sa,Su,PH 10:00-12:00,17:00-19:00) lauten.
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?
Offline
#6 2018-02-28 15:48:24
- Nakaner
- Moderator

- From: Karlsruhe
- Registered: 2011-09-03
- Posts: 3,046
- Website
Re: access:conditional
Generell: access=limited hours ist kein Standartwert und wird daher von den Routern nicht ausgelesen.
Graphhopper hat eine eingeschränkte Unterstützung bedingter Beschränkungen.
Werdet Mitglied in der OSM Foundation und bestimmt über die Zukunft der Foundation und des Projekts mit. Ab 42 Mappingtagen in den letzten 365 Tagen ist es kostenlos. Jetzt beitreten ("Active Contributor Membership")!
Moderator im Bereich users: Austria
Offline
#7 2018-02-28 16:01:22
- milet
- Member

- Registered: 2017-07-13
- Posts: 292
Re: access:conditional
Hast du Beispiele, wo man sich das mal ansehen kann?
Im Wiki das vorletzte Beipiel: "Mo-Su,PH 15:00-03:00; easter -2 days off"
https://wiki.openstreetmap.org/wiki/DE: … ning_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.
Last edited by milet (2018-02-28 16:03:32)
Offline
#8 2018-02-28 16:06:10
- hsimpson
- Member
- Registered: 2015-07-21
- Posts: 675
Re: access:conditional
hsimpson wrote:Dann noch ein paar Zusatzfragen:
Der Weg ist außer an den angegebenen Zeiten komplett gesperrt für alle Benutzungsarten (also auch Fahrzeuge, Fußgänger, etc.)? Nur dann ist access=no korrekt!
Der Weg ist eigentlich eine Brücke über ein Sperrwerk und ist außer zu den angegebenen Zeiten hochgeklappt. Wird die Brücke runter geklappt dürfen nur Radfahrer und Fußgänger passieren.
https://de.wikipedia.org/wiki/Sperrwerk_Wischhafen
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=designateddas 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
Fragen zu PTv2? Vlt mal in diese Übersicht schauen?
Offline
#9 2018-02-28 17:24:50
- Lukas458
- Member
- From: Wuppertal
- Registered: 2017-05-01
- Posts: 467
Re: access:conditional
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).
Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben. Viele Grüße! ![]()
Offline
#10 2018-02-28 17:30:05
- Harald Hartmann
- Member

- From: 98667 Schönbrunn
- Registered: 2014-04-02
- Posts: 3,123
- Website
Re: access:conditional
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
... 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?
Mein aktives Gebiet: Gemeinde Schleusegrund
Fingerprint meines Schlüssels: 71F7 3CD9 B647 9079 6B88 326E 8B8B 72AE 34F9 5AAD
Offline
#11 2018-02-28 18:16:33
- hsimpson
- Member
- Registered: 2015-07-21
- Posts: 675
Re: access:conditional
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
Fragen zu PTv2? Vlt mal in diese Übersicht schauen?
Offline
#12 2018-02-28 19:01:10
- Lukas458
- Member
- From: Wuppertal
- Registered: 2017-05-01
- Posts: 467
Re: access:conditional
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.
Last edited by Lukas458 (2018-02-28 19:16:35)
Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben. Viele Grüße! ![]()
Offline
#13 2018-02-28 19:22:34
- Lukas458
- Member
- From: Wuppertal
- Registered: 2017-05-01
- Posts: 467
Re: access:conditional
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.
Last edited by Lukas458 (2018-02-28 19:23:47)
Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben. Viele Grüße! ![]()
Offline
#14 2018-02-28 19:39:38
- hsimpson
- Member
- Registered: 2015-07-21
- Posts: 675
Re: access:conditional
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=yesDas 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
Last edited by hsimpson (2018-02-28 19:41:43)
Fragen zu PTv2? Vlt mal in diese Übersicht schauen?
Offline
#15 2018-02-28 19:49:11
- hsimpson
- Member
- Registered: 2015-07-21
- Posts: 675
Re: access:conditional
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
Last edited by hsimpson (2018-02-28 19:49:56)
Fragen zu PTv2? Vlt mal in diese Übersicht schauen?
Offline
#16 2018-02-28 20:59:21
- Lukas458
- Member
- From: Wuppertal
- Registered: 2017-05-01
- Posts: 467
Re: access:conditional
Das hast du gut zusammengefasst! Vielen Dank für deine Beiträge, das hat mir wirklich weitergeholfen.
Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben. Viele Grüße! ![]()
Offline
#17 2018-02-28 21:00:13
- hsimpson
- Member
- Registered: 2015-07-21
- Posts: 675
Re: access:conditional
Das hast du gut zusammengefasst! Vielen Dank für deine Beiträge, das hat mir wirklich weitergeholfen.
Keine Ursache ![]()
Fragen zu PTv2? Vlt mal in diese Übersicht schauen?
Offline
#18 2018-03-01 10:17:53
- mbuege
- Member
- Registered: 2008-06-30
- Posts: 13
Re: access:conditional
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)
Offline
#19 2018-03-01 11:03:44
- chris66
- Member

- From: Germany
- Registered: 2009-05-24
- Posts: 10,144
Re: access:conditional
Sieht gut aus.
Mapper aus dem Münsterland.
Offline
#20 2018-03-02 14:29:59
- GeorgFausB
- Member
- From: Probstei, Schleswig-Holstein
- Registered: 2008-10-14
- Posts: 1,916
Re: access:conditional
Moin,
Das hast du gut zusammengefasst! Vielen Dank für deine Beiträge, das hat mir wirklich weitergeholfen.
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
Offline
#21 2018-03-02 15:01:59
- kreuzschnabel
- Member
- Registered: 2015-07-03
- Posts: 6,640
Re: access:conditional
Da soll(te) das generelle access:*=* den 'kleineren' Wert foot=designated übersteuern ...
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
Last edited by kreuzschnabel (2018-03-02 15:02:15)
Offline
#22 2018-03-03 07:30:53
- GeorgFausB
- Member
- From: Probstei, Schleswig-Holstein
- Registered: 2008-10-14
- Posts: 1,916
Re: access:conditional
Ließ seinen Post #11 bitte noch einmal.
Insbesondere die ersten beiden Sätze sowie den letzten Satz.
Offline
#23 2018-03-03 23:47:38
- Lukas458
- Member
- From: Wuppertal
- Registered: 2017-05-01
- Posts: 467
Re: access:conditional
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.
Last edited by Lukas458 (2018-03-03 23:50:31)
Alle Edits meiner Kommentare sind (nur) Typofixes, wenn nicht explizit anders angegeben. Viele Grüße! ![]()
Offline
#24 2018-03-04 07:44:19
- blaubaer11
- Member
- Registered: 2009-07-22
- Posts: 678
Re: access:conditional
...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....
Offline
Pages: 1