Wie 'Richtungswechselbetrieb' bei Straßen taggen?

Hallo zusammen,
wie trägt man den Richtungswechselbetrieb auf der Heerstraße in Berlin, eine der am stärksten belasteten Straßen der Stadt, richtig ein?

(By Axel Mauruszat (Own work) [Attribution], via Wikimedia Commons)

Die Spuren können mittels des roten Kreuzes/grünen Pfeils freigegeben/gesperrt werden. I.d.R. ist die mittlere Spur gesperrt, wird manchmal zur Linksabbiegespur. Zeitweilig wird die mittlere Spur jedoch freigegeben, z.B. in der Hauptverkehrszeit. Auch bei Großveranstaltungen ist dies der Fall. Es sollen auch schon vier Spuren in eine Richtung freigegeben worden sein (vom Hörensagen).

Gibt’s da ein fertiges Tagging-Schema? Oder Ideen wie man’s richtig eintragen kann?

Danke und schöne Grüße :slight_smile:

Edit: Titel angepasst, Danke an ‘Yokr’

Ich habe auch nichts dazu gefunden. Nur den wohl offiziellen Begriff: Richtungswechselbetrieb :wink:

Kenne das von der Golden Gate Bridge in SF, wo mittags ein “Betonplankenversetzer” die Spuren für den Feierabendverkehr Richtung outbound erhöht. Mein Vorschlag wäre in etwa
lanes:forward=1
lanes:forward:conditional=4 @ rush_hour
lanes:backward=1
lanes:backward:conditional=4 @ rush_hour

basierend auf der Wiki Syntax

Es gibt auch 10 Beispiele allerdings wohl mit festen Zeiten, ohne meine rush_hour Erfindung.
Cepesko

Die viel wichtigere Frage wäre doch: was macht Darth Vader mit einem Einkaufsroller da mitten auf einer 5-spurigen Kraftfahrstraße? :wink:

Schwer atmen und keinen guten Eindruck, was sonst?

–ks, auch scnr

Wie haben wir das denn genau getaggt bei der Sierichstraße in Hamburg?

https://de.wikipedia.org/wiki/Sierichstra%C3%9Fe_(Hamburg)

Ich würde das ans Tagging wechselnder Tempolimits anlehnen, also entweder


lanes=5
lanes:forward=signals
lanes:backward=signals

wie hier oder


lanes=5
lanes:variable:forward=yes
lanes:variable:backward=yes

wie hier.

–ks

Ich weiss, dass man nicht für die Renderer taggen sollte, aber das sind ja auch Menschen…
Die Frage ist eben auch, was fangen “wir” mit der Information an, wer kann was damit anfangen und was ?
Einfach immer erfassen was existiert, ohne sich ab und zu zu fragen wozu - ist das das Allseligmachende ?
Peter

„Taggen für den Renderer“ heißt: Sachlich fragwürdige Information eintragen, um ein gewünschtes Kartenbild zu bekommen. Allgemein: Kartenbildoptimierung auf Kosten anderer Anwendungen. Es kann nur das heißen, denn wenn es hieße, dass wir überhaupt nichts taggen dürfen, was der Renderer anschließend darstellen kann, um uns nicht dem Vorwurf des TfdR auszusetzen, dann machen wir das Projekt lieber gleich dicht.

Zum Beispiel können Navis die Warnung ausgeben: „Achten Sie auf die aktuelle Fahrspurbeschilderung“.

Wir mappen ja auch nicht, um selig zu werden, sondern um eine ausführliche, detaillierte und aktuelle Geodatenbank zu bekommen. Wieso wäre es kontraproduktiv, da reinzuschreiben, wo Fahrspuren bedarfsorientiert geändert werden? Wenn du die Information nicht brauchst, dann ignoriere sie. Das mache ich mit amenity=vending_machine+vending=cigarettes ja auch, habe aber trotzdem nichts dagegen, dass sie drinstehen, und hab sogar für meine rauchenden Mitanwender freundlicherweise selbst einige gemappt.

–ks

Ich glaube, mein Kommentar ist zu sehr als Kritik rüber gekommen, was es nicht gemeint war.

Was ich für etwas übertrieben halten würde, wäre der Vorschlag

(Ignorieren wir das “rush_hour”).
Der Benutzer sollte nicht zu viel Information erhalten, die er für verlässlich hält, was sie im Zweifelsfalle eventuell doch nicht ist. Denn das könnte zu kritischen Situationen führen.

Die Warnung, wie du sie vorschlägst, wäre prima und ist viel mehr nach meinem denken.
Gruss Peter

Dast Tagging von http://www.openstreetmap.org/way/167369617 etc lässt sich auf die angefragte Situation also nicht ohne weiteres übertragen?

IMHO nein. Deshalb nicht, weil keine festen Zeiten vorliegen, die man ins :conditional setzen könnte. Da kann man ohne weitere Datenquellen dem Router nur anbieten, einen Warnhinweis „achte auf die aktuelle Signalisierung“ auszugeben.

–ks

Nicht wirklich, weil nicht die komplette Straße ‘umgedreht’ wird. Dennoch finde ich Dein Beispiel sehr gut, weil es Tagging-Möglichkeiten eröffnet.
Desto länger ich über den Fall der Berliner Heerstraße nachdenke, desto mehr denke ich, dass ein ‘description’ o.ä. vielleicht reicht, so lange die Taggingmöglichkeiten derart eingeschränkt wie sie nunmal aktuell wohl zu sein scheinen. Denn: Im Vergleich zu Sierichstraße wird meist ein festes Konzept auf der Heerstraße gefahren (2 Spuren je Richtung, mittlere Spur gesperrt bzw. als Linksabbiegespur).

Ansonsten gibt es noch dieses gaaaanz weit vorangetriebene Proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/Reversible_Lanes (siehe auch den wikipedia-Link dort). Das müsste natürlich schwer ausgebaut und vor allem nochmal gründlich durchdacht werden, naja

Das ist auf jeden Fall vieeeeel schwieriger auszuwerten als ein geeignetes Attribut wie direction_change_operation=yes.

Was hat denn das mit eingeschränkten Taggingmöglichkeiten zu tun? Sag uns, um welche Uhrzeit an welchen Kalendertagen in welcher Mondphase welcher Fahrstreifen in welcher Breite für welche Verkehrsarten wie rum geht und ob er dabei einen roten oder gelben Belag hat, dann lässt sich das alles einzeln an jeden Fahrstreifen taggen. Die Taggingmöglichkeiten reichen dafür mehr als aus.

Das Problem liegt darin, dass wir nicht wissen, wann welcher Fahrstreifen wie rum geht. Und dann können wir es schwerlich drantaggen, oder?

–ks

Das klingt nicht schlecht!

Na, die Taggingmöglichkeiten sind eingeschränkt, weil es offenbar kein festes Schema gibt für den lanes-Regelbetrieb: 2 forward, 2 backward, 1 gesperrt; Abweichungen davon sind jederzeit möglich, werden durch ein fest installiertes Spurleitsystem bekanntgegeben. Die Taggingmöglichkeiten reichen dafür NICHT aus :slight_smile:

Und siehste, dafür reichen die Taggingmöglichkeiten eben nicht aus - jetzt schreibst Du’s ja sogar selbst :smiley:

So genug von dem, all das hilft uns hier so viel weiter wie Darth Vaders unendliche (Einkaufs-)Wege zu ergründen

Nö, ich schrieb, dass wir Informationen, die uns nicht vorliegen, trotz ausreichender Taggingmöglichkeiten nicht taggen können. Aber da du offenbar eine andere Logik hast als ich, belassen wir es dabei.

–ks

Meines Wissens nach sind die 3er Spurenschaltungen immer nach einem geregelten Zeitplan. Morgens 3 rein, nachmittags 3 raus. Wann das aber genau anfängt und endet, weiß vermutlich nur jemand der ständig in der Mitte mit einem Einkaufsroller rüberschlürft. Ich komme da generell nur am Morgen vorbei und habe es meistens als 3-spurig stadteinwärts in Erinnerung.

Auch wenn es jetzt die Meinung eines Neulings ist, finde ich dieses Schema ganz gut:

Das beschreibt für mich eigentlich die tatsächliche Regelung am Besten, nämlich die Regelung über Signalanlagen. Gerade wenn es bei Events (Olympiastadion, ICC) auch angepasst wird, hat man damit trotzdem eine Beschreibung der Situation.

Auf die Schnelle habe ich auch noch diese (etwas ältere) Beschreibung für einen Ersatzbau der Anlagen gefunden. Wenn die darin beschriebenen Detektorenschleifen zB wieder aktiv wären, dann würde sich das ganze System ohnehin nach dem aktuellen Verkersaufkommen richten. Und wenn nicht, wären es immer noch sechs verschiedene Schaltprogramme die man erfassen müsste. Natürlich gut möglich, dass es nach über 10 Jahren anders läuft. Zur Not könnte man ein paar Ämter damit nerven und schauen ob die einen schlauer machen können.

Da mag für den konkreten Fall zumindest für reale Anwendungen sinnvoll sein, allerdings sollten wir grundsätzlich geeignete Taggingmöglichkeiten schaffen, wenn die vorhandenen unzureichend sind.

Es gibt noch ein weiteres Proposal:
https://wiki.openstreetmap.org/wiki/Proposed_features/Suffix_both_ways
Dieses wird zwar schon benutzt, aber soweit ich sehe wurde es noch nicht diskutiert.
Es erscheint mir auch keinesfalls ausgereift zu sein:

  • Wenn eine Fahrspur für beide Richtungen nutzbar ist, kann sie dennoch verschiedene Eigenschaften je Richtung haben. Es fehlt eine Definition wie dieses zu taggen ist.
    [list=*]

  • Verwendet man dazu *:lanes:both_ways:forward und *:lanes:both_ways:backward so wäre dies zwar technisch ok, aber zumindest für eine intuitive graphische Darstellung im Editor ungeeignet, sofern diese sich nicht völlig vom Taggingschema entfernt. Verwirrend wird es auch dadurch, dass z.B. forward in *:lanes:forward dann nicht nur einen Richtungsfilter sondern auch eine Fahrspurfilter darstellt, der Spuren rauswirft, die aber in *:lanes:both_ways:forward enthalten bleiben, wo forward ein reiner Richtungsfilter wäre.

  • Nimmt man die both_ways Spuren mit in die *:lanes:forward und *:lanes:backward Tags mit auf, was aber anhand der Beispiele im Proposal nicht vorgesehen zu sein scheint, hätte man intuitivere Editiermöglichkeiten. Wir hätten aber das Problem, dass nicht feststellbar wäre, welche dieser Spuren eine both_ways Spur ist, da die Anzahl in lanes:both_ways nicht anwendbar ist, da *:lanes und lanes unterschiedliche Definitionen haben, was als Spur zählt.

[/*] [*]Das erste Beispiel im Proposal, die gemeinsame Linksabbiegespur für beide Richtungen innerhalb der Kreuzung, dürfte der Hauptanwendungsbereich des Proposals sein. Allerdings halte ich diese Verwendung für sachlich falsch. Es kann gleichzeitig in beiden Fahrtrichtungen nach links abgebogen werden, also handelt es sich eigentlich um zwei separate Fahrspuren die voreinander nach links abscheren ohne sich gegenseitig zu beeinträchtigen.[/*] [/list]