You are not logged in.

Announcement

*** NOTICE: CONTENT MIGRATION PENDING! Read More about the import. Bug? Post them here***

#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. wink
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

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

Offline

#5 2018-02-28 15:13:01

mbuege
Member
Registered: 2008-06-30
Posts: 13

Re: access:conditional

milet wrote:

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

hsimpson wrote:

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

mbuege wrote:

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

mbuege wrote:
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=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


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! smile

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

Lukas458 wrote:

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! smile

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! smile

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=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

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! smile

Offline

#17 2018-02-28 21:00:13

hsimpson
Member
Registered: 2015-07-21
Posts: 675

Re: access:conditional

Lukas458 wrote:

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

Keine Ursache smile


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,

Lukas458 wrote:

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. wink

Grüße, Georg

Offline

#21 2018-03-02 15:01:59

kreuzschnabel
Member
Registered: 2015-07-03
Posts: 6,640

Re: access:conditional

GeorgFausB wrote:

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! smile

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

Board footer

Powered by FluxBB