Wie tagge ich einen automatisch versenkbaren Poller? Auf der zugehörigen Straße ist zwischen 20:00 und 6:00 der Autoverkehr verboten. In dieser Zeit wird der in der Straße eingelassene Poller automatisch hochgefahren.
Da fehlen dann noch die zeitabhängigen access Tags.
Und da kein OSM Router zeitabhängig routen kann muss man sich überlegen ob man da defaultmäßig das Routing sperren
will oder nicht.
“bollard=rising” kannte ich noch nicht, habe es ergänzt. Leider sieht man hier wieder, wie wirr das Wiki aufgebaut ist. Es gibt einen Eintrag zu barrier=bollard und einen zu bollard allein.
Die Zeitangaben habe ich versucht, mit hour_off/on anzugeben (auch auf dem zugehörigen Straßenabschnitt). Ob und wie es ein Router auswertet - wir taggen nicht für …
Nachsatz: Ich bin für weitere Ideen zu diesem Thema offen.
Meine Herren … 
Dann müssen sie es halt lernen!
Das geht schon in Ordnung mit den zwei verschiedenen Seiten.
bollard=rising/removable ist eine genauere Beschreibung eines spezifischen Wertes (barrier=bollard) des allgemeinen Schlüssels barrier, für den es eine Vielzahl von linearen (Zäune, Hecken, Ketten, …) und punktuellen Werten (diverse Tore, …) gibt.
So ist die normale und und in diesem Fall systematische Vorgehensweise im OSM-Wiki.
PS:
Es gibt zudem noch Barriers mit weiteren Erläuterungen zur Anwendung. Da sind die Einträge nach einer anderen Systematik sortiert und Rendering-Vorschläge für alle beschriebenen Werte enthalten.
Edbert (EvanE)
Ist nicht trivial. Würde mich mal interessieren wie die kommerziellen Navis dort routen.
Mangels eines kommerziellen Routers kann ich das nicht sagen. Gockel und Bingobongo fahren jedenfalls drüber, aber auch Openrouteservice, yournavigation und die Cloudmade Maps erkennen den Poller, obwohl eingezeichnet, nicht. Aber er ist auch erst seit gestern in der Datenbank.
Ganz und gar nicht trivial würde ich sagen, in der Regel weiß man nicht mal wann man dort vorbei kommen wird. Klar hat man eine ungefähre Ankunftszeit, aber die kann sich unterwegs auch ändern. Und dann gibt es noch vorgefertigte Routen als GPX, die sowas gar nicht erst unterstützen. Das reicht demnach von “geht überhauptnicht” bis “geht wahrscheinlich, vielleicht aber auch doch nicht”.
Ich nehme mal an dass der größte Autoverkehr außerhalb von 20-06 Uhr stattfindet, so gesehen könnte man es standardmäßig frei geben. Man könnte aber auch motor_vehicle=destination missbrauchen, wenn es sich nur um einen kleinen Bereich handelt. Von der Bedeutung her dürfte das zumindest etwas ähnlich sein. Sind natürlich leider alles nur Krücken.
Nur weil die Router das noch nicht können, sollte man das aber nicht falsch Taggen. Dann lernen es die Router nie, weil es keine Beispiele und kein Bedarf gibt.
Taggt man es jetzt richtig, besteht für die Router Bedarf. Und die können so etwas dann lernen. Zeitabhängiges Routing ist eigentlich überall wichtig, wie viele Schilder haben Zeitbeschränkungen drauf.
Die ursprüngliche Anregung war ja auch nicht, es falsch zu taggen. “Hier ist Autoverkehr erlaubt, außer zwischen 20:00 und 6:00” und “hier ist Autoverkehr verboten, außer zwischen 6:00 und 20:00” sind beispielsweise beide richtig und würden von einem perfekten Router daher auch identisch behandelt. Der Unterschied ist nur, wie die heute existierenden Router damit umgehen. Und es ist nicht nur erlaubt, sondern auch durchaus sinnvoll, das in seine Überlegungen einzubeziehen.
Genau, und ich persönlich würde mich da vom Verkehrsaufkommen leiten lassen, mich also fragen, wieviele Fahrzeuge
wollen wohl den Weg zwischen 6:00 und 20:00 Uhr, und wieviele zwischen 20:00 und 06:00 Uhr nutzen.
Das finde ich gefährlich. Was ist, wenn in dem Moment grad ein Kinderwagen dort steht? Also da scheint mir ein hazard=* angebracht.
Dass drüber geroutet wird, ist vertretbar. Im schlimmsten Fall muss man halt 10h warten, bis man weiterfahren kann. Der Unterschied zu einer Ampel oder einem Bahnübergang ist nur quantitativ.
Ich würde da opening_hours=* taggen, dann ist klar wann da offen ist. Was dann irgendwelche Router draus machen, muß man sehen, die nötigen Infos, wann man da durch kann, sind dann jedenfalls erfaßt und das Problem hier an den Routern, sie auch auszuwerten. Deswegen würde ich nicht den subjektiv empfundenen überwiegenden Zustand als access=* erfassen, weil das wäre ja dann Tagging für den Router.
Bedeutet “opening_hours” nicht Öffnungszeiten?
Über “hazard” könnte man durchaus nachdenken. Allerdings steht am linken und rechten Straßenrand ein Warnlicht, das wie bei einem Bahnübergang vorher zu blinken beginnt. Bei einem Bahnübergang taggen wir auch nicht das “hazard”.
Warten muss man nicht, man kann auch umkehren und einen anderen Weg wählen, schlimmstenfalls über die Umfahrungsstraße des Ortes. Das Gebiet ist ohnehin verkehrsberuhigte Zone mit Fahrverbot von 22:00 bis 6:00, nur bei dieser Straße beginnt das Fahrverbot schon um 20:00.
Im Prinzip ja.
Wiki (access):
A more flexible solution for time-dependent tagging is using access:<opening_hours value>=* as proposed by Extended conditions for access tags.
Ich vermute, dies hat Fabi2 gemeint.
Das wäre dann sowas wie: motorcar:(20:00-06:00)=no
War das, wenn ich die access-Debatte richtig verfolgt habe, nicht in dieser Form verpönt? Müsste es nach den letzten Diskussionsergebnissen nicht motorcar:no=(20:00-6:00) heißen?
Nein, ich meinte den normalen opening_hours=*-Key, weil damit gibt man ja an, das eine Sache irgendwann geöffnet hat, also die Öffnungszeiten. Wenn man den Tag zusammen mit bollard=rising an einem Poller einsetzt, dann ist doch naheliegend, das damit die Zeit gemeint ist, in der man da die Einfahrt durchfahren kann. Die variablen Keys heiße ich nicht für gut und habe auch gegen das “Extended conditions for access tags”-Proposal gestimmt.
klar, aber steter Tropfen höhlt den Stein. Wenn man es immer wieder in dieser (banned?) Form erwähnt, sickert das langsam ein. Könnte man auch als “Lobbyarbeit” bezeichnen 
Gruss
Walter
Sollen die Verfechter dieses Vorschlags es doch noch so oft erwähnen oder so taggen, das es nicht sinnvoll auswertbar ist, das wurde ihnen ja gesagt, somit dient es nur dazu, den Speicherplatzbedarf für die Datenbank zu erhöhen.