Warum einfach, wenn's auch kompliziet geht? – Proposal Traffic Signals

MapFactor: GPS Navigation unterstützt turn:lanes:forward/backward

Skobbler unterstützt momentan soweit ich weiß weder turn:lanes, turn:lanes:forward/backward noch maxspeed:forward/backward, zumindest bei meinem letzten Test. Da wird ja momentan viel umstrukturiert nach dem Verkauf an Telenav.

Das müssen diejenigen beantworten können, die es auswerten. Ich mappe nur. :smiley:

Ja.

Es ist eine Frage was man ausgewertet haben möchte. Ich kann schnell erkennen ob ein Fußweg Fahrradweg vorhanden ist und ggf. auch in welcher Richtung der Radweg verwendet werden darf. Aber das ist schon schwerer!
Ebenfalls leicht rauszufinden ist wer es denn benutzen darf. Aber schon mit den Oberflächen wird es schwer. Welcher Weg hat jetzt welche Oberfläche. Gehen wir mal davon aus das alle Wege anders beschaffen sind. Auch der Pflegezustand und die Abnutzung dürfte sich stark unterscheiden.
Was sollte dann ein Navi dem Rollatorfahrer für einen Vorschlag machen?

Ich wäre schon zufrieden, wenn die örtlichen Mapper gefragter wären, denn die sind es, die ihre Umgebung aktuell halten.

Warum haben 3-4 Mapper entschieden, dass eine Doppellinie nicht mehr baulicher Trennung entspricht?
Warum setzen 4-6 Mapper deutschlandweit ihre Ideen schnellsten um (und schaffen sich Argumente, es wird ja in Deutschland so gemappt - nun machen wir es noch in den anderen Ländern)
Warum wird im WIKI ständig etwas geändert?

Ich versuchte die mir bekannte Gegend aktuell zu halten. Wenn aber Mapper aus 200- 300 km Entfernung - ohne vor Ort gewesen zu sein - es besser wissen … Ich habe auch Fehler gemacht, dazu stehe ich auch. Ich finde lanes=* als Spurbezeichnung auf mehrspurigen hw durchaus angebracht. Mittlerweile geht es um detaillierteres mappen - warum nicht hw=lanes als way. Es gibt einige Vorschläge Straßen als Flächen anzulegen (ähnlich waterway). Sollten wir nicht auch andere Meinungen akzeptieren. Wenn ich keine verschiedene Beispiele habe, kann ich auch nicht entscheiden, was ist besser. Ich bewundere andere (netzwolf, maxbe, …) die wenigsten versuchen, welche Möglichkeiten bei verschiedenen Situationen es gibt.

OSM war für mich etwas mehr als Hobby. Ich war bestrebt, Nutzer im Umfeld von “besseren Karten” zu überzeugen und ihre Vorstellungen mit zu beachten: (@anonym: Eine Gasse oder ein Weg von 2.5 m breite ist m.E. kein hw=residential).

OK. Danke. Das werde ich mir dann auch mal anschauen wenn mein Handy aus der Displayreparatur zurück ist.
Das Programm kannte ich noch nicht.

Hallo,

ich habe das Proposal erstellt und freue mich über das viele feedback. Ich habe darauf basierend eine neue Version des Proposal erstellt. Ihr findet es unter der alten Adresse:

http://wiki.openstreetmap.org/wiki/Proposed_features/Traffic_Signals

Ich habe eingesehen, dass das Proposal sehr viele Relationen für eine Kreuzung bedingt hätte und habe die benötigte Anzahl verringert. Nun ist nur noch eine Relation pro eingehender Kante in eine Kreuzung (Kann aus mehreren Knoten bestehen) notwendig. Also in der Regel zwischen 2 und 4.
Der Alternativvorschlag von Michael sah, wenn ich es richtig verstanden habe, so aus, dass auf Relationen komplett verzichtet wird und die Informationen in den traffic_signal Knoten getagged werden sollen. Ich glaube allerdings dass dies nur funktioniert wenn der Knoten nur auf einem der Wege liegt. Liegt er genau auf Kreuzung von Zwei Wegen, bzw. auf dem Ende von 4 Wegen ist mir schleierhaft wie man festlegen soll für welche eingehende Kante welche Ampelphase gilt.

Die Referenzierung der turn:lanes scheint mir auch sinnvoll da es einfacher zu taggen und robuster gegen Änderungen ist. Ich habe das vorgeschlagene Schema größtenteils in mein Proposal übernommen.

Die Möglichkeit mit conditional Zeitabhängige Schaltungen zu modellieren ist auch eine sinnvolle Idee und kann optional benutzt werden.

Dass dynamische Ampelschaltungen existieren ist mir bewusst. Es geht vielmehr um eine Idee wie wahrscheinlich es ist dass eine Ampel grün oder rot ist. Daher habe ich das taggen der Phasen auch vereinfacht.

Die Deklaration von via-ways habe ich auch erstmal herausgenommen, da diese relativ einfach von einem router ermittelt werden können da ein to-way angegeben ist.

Ich würde euch darum bitten das überarbeitete Proposal nochmals durchzugehen und würde mich freuen wenn ihr mir eure Gedanken dazu mitteilt. Am besten auf der Diskussionsseite zu dem Proposal.

Grüße

Lukas

Hallo Lukas,

Ich bin davon ausgegangen, dass Kreuzen, bei denen man sogar die Ampelphasen mappt, der Ampelknoten nicht mehr die Kreuzungsmitte, sondern an den Haltelinien/Fußgängerfurten liegt. Der Ampelknoten läge dann auf einem Node, der maximal drei Ways angehört – der Fahrbahn für den Kfz- und Radverkehr und dem kreuzenden Fuß-/Radweg, der an dieser Stelle aufgeteilt sein darf, wenn er kein Einbahnfußweg ist. Wie lange die Grünphase des kreuzenden Fuß-/Radweg ist, kann man dann mit phases:crossing=* angeben.

Mit dem Schema kann ich mich anfreunden. Ein nützlicher Nebeneffekt könnten verbesserte Abbiegeansagen bei Navis sein. Wenn ein Mensch als Rolle “to:left” vergibt, wird das wohl auch von anderen Menschen als “links” empfunden. Hoffentlich aber nicht “too:left”, was “zu weit links” bedeutet. :slight_smile:

Viele Grüße

Michael

Ich frage mich wo hier die Doppellinien sind, von denen du die ganze Zeit redest.

Hallo,

Das Proposal steht nun zur Abstimmung bereit. Ich würde mich sehr über eure Stimme freuen oder eine weitere Konstruktive Kritik.

http://wiki.openstreetmap.org/wiki/Proposed_features/Traffic_Signals#Voting

Vielen Dank

Moin,

der Zeitverlust an einer Ampelkreuzung wird durch die Parameter

  1. Verkehrsdichte (können alle wartenden Fahrzeuge in einer Grünphase passieren oder müssen sie mehrfach anfahren)
  2. passende Schaltung aufeinander folgender Ampelanlagen (grüne Welle)
  3. Länge der Rot- und Grünphasen
  4. Sondereffekte durch Induktionsschleifensteuerung, Fussgängeranforderung, Busvorrangschaltung
    bestimmt.

Die Relation gibt Punkt 3 wieder (sofern der Mapper die Ampel lange genug beobachtet um die mittleren Phasenlängen korrekt zu bestimmen).
Ein Router kann damit den Zeitverlust berechnen, wenn das Fahrzeug die Ampel in der nächsten Phase überqueren kann, das Eintreffen nicht von vorherigen Ampeln getaktet ist (erste Ampel nach freier Strecke) und es keine Sondereffekte durch Punkt 4 gibt.
Dafür erscheint mir der Aufwand recht hoch.
Gibt es weitere Anwendungen?

Die Relation ist komplex, so dass es schwierig ist, die Daten auf Korrektheit zu überprüfen.

Hallo,
also ich empfinde das als sehr kompliziert und mehr als fehleranfällig. Auch habe nicht verstanden, ob die Abbiegerelationen bei Ampeln, welche nicht im Kreuzungsnode sondern an der Haltelinie getaggt sind, genauso aussehen müssen/werden?
Wenn ich mir diese Kreuzungsansammlung ansehe http://www.openstreetmap.org/#map=17/51.36387/7.46436, dann müsste ich, da ich nicht überall abbiegen kann wohin ich will, 35 Relationen erstellen, sofern ich richtig gezählt habe (da an einer Kreuzung auch jede Richtungsänderung gesondert geschaltet ist). Solche Kreuzungshäufigkeiten kommen gerade in Großstädten häufig vor und sind mehr als unübersichtlich. Und jetzt wird an einer Straße etwas geändert…viel Spaß bei der Wartung der Relationen…

Kann es sein, dass du eine veraltete Version des Proposals im Kopf hast? So war das im ersten Entwurf, den ich deshalb auch als zu kompliziert kritisiert habe. Mittlerweile braucht man aber nur noch eine Relation pro Straße, die auf die Kreuzung zuführt. Es ergäbe in deinem Beispiel also:

Kreuzung Graf-von-Galen-Str./Körnerstr.:
1 Relation aus der Graf-von-Galen-Str.
1 Relation aus der südöstlichen Körnerstraße
1 Relation aus der nordwestlichen Körnerstraße

Kreuzung Körnerstraße/Am Hauptbahnhof:
1 Relation aus der südöstlichen Körnerstraße
1 Relation aus der nordwestlichen Körnerstraße

Kreuzung Märkischer Ring/Eckeseyer Str./Altenhagener Str./Körnerstr.:
1 Relation aus der Körnerstraße
1 Relation aus der Altenhagener Str.
1 Relation aus der Eckeseyer Str.
1 Relation vom Märkischer Ring

Das ergibt in der Summe also 9 Relationen. Die Kreuzungen haben vermutlich mehr Abbiegebeschränkungsrelationen als Ampelphasenrelationen. :slight_smile:

Da die Rollen der Mitglieder jetzt auch die Abbiegerichtung enthalten turn:left, turn:slight_left, … und diese Abbiegewerte dem Spurmapping entstammen, können Router statt zur Ampelphasenschätzung die Relationen auch für Abbiegeanweisungen verwenden.

Ich habe gerade eben {{vote|yes}} --~~~~ ergänzt.

Viele Grüße

Michael

Ja, so habe ich das verlinkte Proposal verstanden.
O.k., 9 Relationen obwohl die Ampelphasen je Abbiegung unterschiedlich sind?

Ja. Die Relation hat für jede Abbiegerichtung ein eigenes Tag, also phases:left=, phases:slight_left= usw. Tageszeitabhängigkeiten sind auch möglich, indem man ein “:conditional” anhängt.

Nun ja, es bietet immerhin viele Möglichkeiten. Aber die Unübersichtichkeit bleibt erstmal, insbesondere bei der Wartung auch wenn es nur 9 statt 35 Relationen sind. Bei den Abbiegebeschränkungen gibt es eine gute Hilfe (auch unter Potlach), hier müsste erstmal ein entsprechendes Tool gebaut werden, ist denn so etwas in realistischer Zeit umsetzbar? Ich kann mir vorstellen, dass man auch bei 9 Relationen an diesem Kreuzungsgemenge aus meinem Link den Überblick verliert.

Was macht dich so sicher, dass man durch langes Beobachten die Ampelphasen im Durchschnitt berechnen kann?
Gehen wir einmal von der grünen Welle in Dresden zwischen Friedrich-List-Platz bis nach Prohlis aus. So gibt es dort bereits drei Programme die in Abhängigkeit der Verkehrsstärke geschaltet werden. Dazu kommen Sondersituationen wie Autobahnsperrung und Verkaufsoffener Sonntag oder Fußballspiel.
Daraus folgt:

  1. Der Durchschnitt sagt gar nichts über meine aktuelle Situation aus!
  2. Ein Mapper muss schon sehr lange warten bis er jedes Programm auch nur gesehen hat. Insbesondere wenn er keine Kenntniss davon hat, dass es diese gibt.

Um dem ganzen eins drauf zu setzen, wird jetzt auf der anderen Route ein selbtsoptimierendes Ampelsystem aufgebaut, welches statt einer stumpfen Vorangschaltung (Anmelden das das eingeräumte Zeitfenster auch genutzt werden soll) auch noch die Fahrplanlage der öffentlichen Verkehrsmittel berücksichtigt. Das heißt die Ampel wird sich bei einem verspäteten Bus anders verhalten, als wenn er zu früh ist. Bei der aussagekräftigen Abbildung dieses Sachverhaltes wie auch immer, wünsche ich viel Spaß!

Nun ja, es bietet immerhin viele Möglichkeiten. Aber die Unübersichtichkeit bleibt erstmal, insbesondere bei der Wartung auch wenn es nur 9 statt 35 Relationen sind. Bei den Abbiegebeschränkungen gibt es eine gute Hilfe (auch unter Potlach), hier müsste erstmal ein entsprechendes Tool gebaut werden, ist denn so etwas in realistischer Zeit umsetzbar? Ich kann mir vorstellen, dass man auch bei 9 Relationen an diesem Kreuzungsgemenge aus meinem Link den Überblick verliert.

Der beobachtete Durchschnitt muss mathematisch mit zunehmender Beobachtungszeit gegen den realen Durchschnitt konvergieren.

Das war auch mein Kritikpunkt. Straßenzüge mit grüner Welle zu erfassen dürfte für einen Router ein weit größerer Vorteil als die Ampelphasen sein.
Wie ein Router die Länge der Ampelphasen zur Berechnung der Fahrzeit nutzen kann, ist mir nicht klar.
Auf Hauptstraßen mit langer Grünzeit staut sich der Verkehr vielerorts häufiger, als auf Nebenstraßen mit kurzer Grünzeit.

Bislang ging es nur um die Ampeln für den Kfz-Verkehr. Innerstädtisch gibt es aber auch viele Ampeln für Radfahrer.
Beim Linksabbiegen haben Radfahrer in der Regel eine rote Welle (sie müssen dann immer vor der zweiten Ampel warten).
Das lässt sich durch die vorgeschlagene Ampelrelation m.E. nicht abbilden.

Klar bekommst du irgendwann einen mathematischen Durchschnitt für den Tag. Aber das ist nicht sinnvoll, wenn die Ampel frühmorgens für die eine Richtung und abends für die andere Richtung länger grün zeigt. Dann ist deine Wartezeit von der Zeit in der du fährst und nicht von dem Durchschnitt.

Wie ein Router sowas verwenden könnte? Die mittlere Wartezeit beträgt immer die Hälfte der Rotzeit für deine Richtung. Wenn du allerdings mehrere Zeitfenster hast (Linksabbieger vor oder nach den Geradeausfahrern) dann ist die Rechnung schon komplexer aber ähnlich.
Wenn du eine Grüne Welle hast ist der Ansatz aber hinfällig, da der Zustrom dann nicht mehr Normalverteilt ist.