OpenStreetMap Forum

The Free Wiki World Map

You are not logged in.

#1 2015-01-17 17:44:55

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 2,590
Website

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

Hallo,

dank @timetabling auf Twitter (Entwickler von Graphhopper) bin ich auf ein Proposal für Ampelkreuzungen gestoßen, das ich auch nach zweimaligem Durchlesen noch nicht richtig verstanden habe (sic!).

https://wiki.openstreetmap.org/wiki/Pro … ic_Signals

Was mich daran stört ist die unnötige Komplexität für jede Abbiegerichtung eine Relation. Ja geht's noch? Da muss man bei einer ganz normalen X-Kreuzung, wo alle Abbiegevorgänge erlaubt sind, 12 (mit Wenden 16) Relationen anlegen und pflegen! Viel Spaß mit den iD-Newbies.

Desweiteren werden variable Keys verwendet, was den Nutzern von OSM-Daten gar nicht gefallen dürfte. Zum Glück ist das Schema abwärtskompatibel, sprich man braucht als Nutzer das Schema nicht zu implementieren.

Wie soll es denn ein 08/15-JOSM-Nutzer verstehen, wenn selbst ich es nicht verstehe? Es ist in meinen Augen ein gravierender Verstoß gegen den KISS-Grundsatz. Besonders treffend finde ich den Kommentar von ubahnverleih: "warum heißt es nicht gleich 'simple Traffic Signals'?"

Ich lade hiermit alle Interessierten dazu ein, kräftig Gegenwind zu pusten. Bei dem polnischen Grabstein-Sammelrelationsproposal hat das auch so gut geklappt, dass die Steine umgefallen sind. :-)

Viele Grüße

Michael


Ein aussagekräftiger Änderungssatzkommentar gehört zum guten Ton.
Moderator im Bereich users: Austria.

Offline

#2 2015-01-17 18:06:27

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 2,590
Website

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

Hallo,

gleich noch ein Alternativvorschlag:

Ampelgrünphasen kann man auch einfacher mappen. Bei einer Ampel erfasst man:
1. die Richtung, für die sie gilt mit traffic_signals:direction=forward/backward
2. die Gründauer je Abbiegerichtung mit den Tags traffic_signals:green:left=*, traffic_signals:green:slight_left=*, traffic_signals:green:through=*, … Ich weiß nicht, ob es sinnvoller ist, als Wert Prozentangaben oder Anteile vorzuschreiben (als 20 % für 20 % durchschnittlich Grünanteil pro Minute oder 40/120 für 40 Sekunden Grün in einem 120 Sekunden dauernden Zyklus) oder den Zyklus vorzugeben (r30ry1g10y2 für 30 Sekunden Rot, dann 1 Sekunde Rot-Gelb, dann 10 Sekunden Grün, dann 2 Sekunden Gelb).

Auf jeden Fall kommt dieser Vorschlag ohne Relationen aus. Ich bin kein Freund von Notationen wie traffic_signals:green=20|50|50|70, wo jedem Fahrstreifen wie bei turn:lanes eine Gründauer zugeordnet wird. Diese Notation ist nämlich zu fragil. Wenn jemand die Fahrstreifenzahl ändert (z.B. getrennt gemappte Spur an die Hauptfahrbahn "andockt" oder abtrennt), passt die Zuordnung nicht mehr.

Mit  traffic_signals:green:left:conditional=* könnte man die Gründauer auch in Abhängigkeit von der Tageszeit und dem Wochentag erfassen, wenn man nichts Besseres zum Mappen mehr hat.

Übrigens, für Bahnübergänge gibt es schon ein Tag für die Schließzeit – railway:level_crossing:closure:average=<Zeit in Minuten>. (Es gibt Bahnübergänge mit Schließzeiten von 5 Minuten und mehr)

Viele Grüße

Michael


Ein aussagekräftiger Änderungssatzkommentar gehört zum guten Ton.
Moderator im Bereich users: Austria.

Offline

#3 2015-01-17 20:18:40

viw
Member
Registered: 2010-05-15
Posts: 2,623

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

mhhh das du keinen Grund für Relationen siehst, verstehe ich nicht. Wie willst du denn vernüftig erschließen welche Richtung Links ist und was unter rechts und Geradeaus zu verstehen ist?
Schon die Ansagen beim Router machen eigentlich deutlich das dies automatisch in unseren Daten nicht so richtig zuordenbar ist und daher Hilfen notwendig sind um wirklich Richtungen zuordnen zu können.

Wie man Grünphasen angeben will ist mir noch ein Rätsel. Aber wenn man es macht ist es immer besser 40/120 zu benutzen als von 20% zu sprechen. Da dort noch mehr Informationen drin stecken. Außerdem ist die Wahrscheinlichkeit einer Wartezeit bei 120 Sekunden umlauf größer als bei 60 Sekunden.

Und nicht zuletzt sollte man nicht vergessen das die meisten Lichtsignalanlagen mehrere Programme je nach Tageszeit und Verkehrsbelastung beherschen. Das ist mit Tags gar nicht abbildbar und hat auch für das Routing keinen Mehrwert. Solche Dinge kann man aber nicht an einer Lichtsignalanlage sehen. Das ist Insiderwissen.

Offline

#4 2015-01-17 20:26:02

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 2,590
Website

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

Hallo viw,

viw wrote:

mhhh das du keinen Grund für Relationen siehst, verstehe ich nicht. Wie willst du denn vernüftig erschließen welche Richtung Links ist und was unter rechts und Geradeaus zu verstehen ist?

Mein Gedankengang: Ein Router, der Ampelphasen unterstützt, unterstützt auch Fahrstreifen. Wenn er turn:lanes*=* unterstützt, dann weiß er (durch die Hervorhebung der richtigen Fahrstreifen/Pfeile in der Anzeige/Ausgabe, in welche OSM-Richtung (left, slight_left, …, right, u-turn) er einen schickt. Mit dieser Information wertet er traffic_signals:green:left/slight_left/…=* aus.

Schon die Ansagen beim Router machen eigentlich deutlich das dies automatisch in unseren Daten nicht so richtig zuordenbar ist und daher Hilfen notwendig sind um wirklich Richtungen zuordnen zu können.

viw wrote:

Wie man Grünphasen angeben will ist mir noch ein Rätsel. Aber wenn man es macht ist es immer besser 40/120 zu benutzen als von 20% zu sprechen. Da dort noch mehr Informationen drin stecken. Außerdem ist die Wahrscheinlichkeit einer Wartezeit bei 120 Sekunden umlauf größer als bei 60 Sekunden.

Und nicht zuletzt sollte man nicht vergessen das die meisten Lichtsignalanlagen mehrere Programme je nach Tageszeit und Verkehrsbelastung beherschen. Das ist mit Tags gar nicht abbildbar und hat auch für das Routing keinen Mehrwert. Solche Dinge kann man aber nicht an einer Lichtsignalanlage sehen. Das ist Insiderwissen.

Man kann es eigentlich nur durch Beobachtung (fünf Minuten Ampelstudium oder Pendlerwissen) ermitteln. Im Prinzip wird es ähnlich laufen wie bei Bahnübergängen, nur dass es über den Tag und die Wochentage mehr Schwankungen gibt. Ausschaltzeiten (wann die Ampel nur gelbes Blinken zeigt) kenne ich als Nicht-Ampeltechniker bei den Ampeln in Dessau [1] und einer in Karlsruhe meist besser als die Schaltung selbst.

Viele Grüße

Michael


[1] Dort können Router bei gefühlt 70 % der Ampeln Mo-Sa ab 19 Uhr und sonntags ganztägig highway=traffic_signals ignorieren.


Ein aussagekräftiger Änderungssatzkommentar gehört zum guten Ton.
Moderator im Bereich users: Austria.

Offline

#5 2015-01-17 20:29:19

seichter
Member
Registered: 2011-05-21
Posts: 2,671

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

Modernere Lichtsignalanlagen werden teilweise von Verkehrsrechnern abhängig vom Verkehrsaufkommen gesteuert.
Da hat man mit Tagging nicht die Spur einer Chance. Das sehe ich aber als Luxusproblem an.

Offline

#6 2015-01-17 21:02:40

Marqqs
Member
Registered: 2011-01-01
Posts: 724

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

seichter wrote:

Modernere Lichtsignalanlagen werden teilweise von Verkehrsrechnern abhängig vom Verkehrsaufkommen gesteuert.
Da hat man mit Tagging nicht die Spur einer Chance. Das sehe ich aber als Luxusproblem an.

Nicht nur das. Besonders in Vorstädten und auf dem Land gibt es zahlreiche verkehrsabhängige Stuerungen, ohne dass die Anlagen an einen Verkehrsrechner angeschlossen wären.

In Großstädten gibt es einen erheblichen Anteil an Anlagen mit Vorrangschaltungen für Bus und Tram. Da kann die Schaltung alle 2 Minuten anders laufen.
Außerdem gibt es dann noch einige Anlagen, die gelegentlich für ein paar Minuten nur in eine Richtung Grün zeigen, nämlich entlang der Feuerwehr-Ausrückroute.

Und wenn irgendwo eine größere Veranstaltung ist, werden Sonderprogramme geschaltet. Ich kenne Anlagen, da sind zwischen 10 und 20 verschiedene Programme hinterlegt.

--> Es ist möglicherweise nicht sehr sinnvoll, die Grünzeiten zu erfassen...

Offline

#7 2015-01-17 21:21:53

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,228
Website

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

Marqqs wrote:

--> Es ist möglicherweise nicht sehr sinnvoll, die Grünzeiten zu erfassen...

+1

Wir haben bei uns eine Ampel, bzw Ampelanlage, die wirklich klasse geschaltet ist. Kommt wer von Norden und will nach Osten, gibt es nach ca 30 Sekunden grün und die Phase dauert solange, bis alle Fahrzeuge durch sind. Danach kriegt die B260 wieder durchgehend freie Fahrt. Fast so gut wie ein Kreisverkehr.

Viel Spass beim Taggen: https://www.openstreetmap.org/node/1405348397

Gruss
walter

Offline

#8 2015-01-17 21:33:07

chris66
Member
From: Germany
Registered: 2009-05-24
Posts: 9,471

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

Ojee, ich hoffe Du wohnst hier nicht im Haus Nummer 2.... wink

https://www.openstreetmap.org/#map=19/50.10828/8.09507


Mapper aus dem Münsterland/NRW. Nicht auf fakebook.

Offline

#9 2015-01-17 21:49:28

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,228
Website

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

chris66 wrote:

Ojee, ich hoffe Du wohnst hier nicht im Haus Nummer 2.... wink

https://www.openstreetmap.org/#map=19/50.10828/8.09507

Nee, sieht schlimmer aus als es werden soll: von Süden kommend wird das ein Tunnel, der dann nördlich von Haus Nr 8 eine Brücke werden soll. Hab die geplante Umgehungsstraße nicht erfasst, aber werde das mal eben anpassen. aber die war auch schon richtig (Tunnel/Bridge) drin. Nur dem Renderer scheint das wohl egal zu sein (?).

Gruss
walter

edit: war doch schon ok.

Last edited by wambacher (2015-01-17 21:54:51)

Offline

#10 2015-01-27 14:22:05

Seoman
Member
Registered: 2011-07-14
Posts: 61

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

Hallo,

Nakaner wrote:

Bei einer Ampel erfasst man:
1. die Richtung, für die sie gilt mit traffic_signals:direction=forward/backward

Das ist ein Tag, der mich schon lange stört. Ich wollte dazu längst mal ein Proposal machen, um es loszuwerden bevor es sich zu sehr verbreitet (die - recht einfache - Idee dazu steht schon, ich schiebe es nur immer wieder vor mir her, daraus ein Proposal zu machen bzw. eine Diskussion anzustoßen).

Der Grund für meine Ablehnung ist folgender: Wir weisen hier einem node eine Richtung zu, das ist höchst unlogisch und hat auch Konsequenzen.

traffic_signals:direction=forward/backward funktioniert nur so lange, wie die Wegsegmente neben dem node in dieselbe Richtung weisen. An der Position der Ampel kann jedoch schnell mal ein Weg gesplittet und/oder umgedreht werden. Als Folge habe ich z.B. einen Ampel-Knoten zwischen zwei Wegen, die beide von der Ampel wegzeigen
--> traffic_signals:direction=forward/backward ist nicht mehr auswertbar!

Seoman

Offline

#11 2015-01-27 14:33:12

Jojo4u
Member
Registered: 2014-08-03
Posts: 1,090

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

Seoman wrote:

Hallo,

Nakaner wrote:

Bei einer Ampel erfasst man:
1. die Richtung, für die sie gilt mit traffic_signals:direction=forward/backward

Das ist ein Tag, der mich schon lange stört. Ich wollte dazu längst mal ein Proposal machen, um es loszuwerden bevor es sich zu sehr verbreitet (die - recht einfache - Idee dazu steht schon, ich schiebe es nur immer wieder vor mir her, daraus ein Proposal zu machen bzw. eine Diskussion anzustoßen).

Der Grund für meine Ablehnung ist folgender: Wir weisen hier einem node eine Richtung zu, das ist höchst unlogisch und hat auch Konsequenzen.

traffic_signals:direction=forward/backward funktioniert nur so lange, wie die Wegsegmente neben dem node in dieselbe Richtung weisen. An der Position der Ampel kann jedoch schnell mal ein Weg gesplittet und/oder umgedreht werden. Als Folge habe ich z.B. einen Ampel-Knoten zwischen zwei Wegen, die beide von der Ampel wegzeigen
--> traffic_signals:direction=forward/backward ist nicht mehr auswertbar!

Danke, das brennt mir auch auf den Nägeln. Was ist deine einfache Lösung?

Last edited by Jojo4u (2015-01-27 14:33:28)

Offline

#12 2015-01-27 15:00:37

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 2,590
Website

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

Hallo,

Seoman wrote:

Hallo,

Nakaner wrote:

Bei einer Ampel erfasst man:
1. die Richtung, für die sie gilt mit traffic_signals:direction=forward/backward

Das ist ein Tag, der mich schon lange stört. Ich wollte dazu längst mal ein Proposal machen, um es loszuwerden bevor es sich zu sehr verbreitet (die - recht einfache - Idee dazu steht schon, ich schiebe es nur immer wieder vor mir her, daraus ein Proposal zu machen bzw. eine Diskussion anzustoßen).

Der Grund für meine Ablehnung ist folgender: Wir weisen hier einem node eine Richtung zu, das ist höchst unlogisch und hat auch Konsequenzen.

traffic_signals:direction=forward/backward funktioniert nur so lange, wie die Wegsegmente neben dem node in dieselbe Richtung weisen. An der Position der Ampel kann jedoch schnell mal ein Weg gesplittet und/oder umgedreht werden. Als Folge habe ich z.B. einen Ampel-Knoten zwischen zwei Wegen, die beide von der Ampel wegzeigen
--> traffic_signals:direction=forward/backward ist nicht mehr auswertbar!

Wie willst du etwas loswerden, wofür die keine Alternative hast? Das wird mir zur Zeit in der associatedStreet-Relation von Mappern/Diskussionsteilnehmern aus dem Ausland vorgeworfen.

Das Problem gibt es auch bei Eisenbahnsignalen, die genau wie Ampeln fast immer (es gibt wenige Ausnahmen) nur für eine Fahrtrichtung gelten. Dort sind das Tags railway:signal:direction=forward/backward/both in Gebrauch. Es gibt aber keine andere vernünftiger Lösung, Geltungsrichtungen zu erfassen.

Ansätze die Geltungsrichtung als Winkel in Grad anzugeben,  sind Overkill und eine genauso große Quelle für falsche Daten.

(1) Der Mapper müsste dann nämlich den Winkel ermitteln. Mit den heutigen Editoren geht das nicht gut. Selbst wenn es einen Tags die Möglichkeit gäbe, in JOSM-Objektvorlagen einen Winkelmesser einzubauen, wäre das nicht der richtige Weg. Es gibt auch noch andere Editoren als JOSM. Sei es iD oder spezialisierte Editoren. Der erhöht für die Nutzer und die Editoren-Entwickler nur die Hürde beizutragen bzw. einen Editor zu programmieren. Bei OSM wollen wir jedoch die Schwelle niedrig halten (KISS), sonst würden wir heute schon die Signal- oder Ampelrichtung als Relation erfassen, die zwei Nodes referenziert – einen from-Node und einen signal-Node.

(2) Winkel sind als Einheit noch uneindeutiger als forward/backward/both. Ich wundere mich bis heute, wie gut das mit Längeneinheiten klappt und ob nicht doch in England ein Großteil der Längen- und Gewichtsangaben in OSM vom Mapper als britische Einheit eingegeben wurde, aber mangels Angabe der Einheit von allen Nutzern als metrisch interpretiert wird. [1] Es gibt zwei verschiedene Drehrichtungen, die der Mathematiker, Naturwissenschaftler und übrigen Ingenieure und die geodätische. Die Geodäten drehen im Uhrzeigersinn, der Rest gegen den Uhrzeigersinn. Dazu kommt die Frage, welche Achse den Winkel 0° hat. Ist es die Rechtsachse (mathematisch x-Achse, geodätisch y-Achse) oder die Hochachse (mathematisch y-Achse, geodätisch die x-Achse)? Und wenn das noch nicht genug wäre, gibt es noch einen dritten Fallstrick, die Einheit. Es gibt Altgrad (°), Neugrad (gon) und das Bogenmaß. Auswerter dürfen sich dann, als wenn das nicht genug wäre, auch noch mit verschiedenen Notationen herumärgern – Winkel in Grad, Minuten und Sekunden vs. dezimal.

(3) Wenn ich als Datennutzer von einer Routing-API den zubefahrenden Weg bekomme, möchte ich mich nicht noch mit der Geometrie herumärgern, wenn ich die Route nicht auf einer Karte zeichnen möchte. Nehmen wir das Beispiel eines Eisenbahnrouters. Er hat als Ausgabe einen tabellarischen Buchfahrplan. Das ist ein Tabelle mit Spalten für Höchstgeschwindigkeit, Signale und Kilometrierung. Wenn die Routing-API mir die befahrenen Wege und die Nodes mit ihren Tags zurückgibt, brauche ich nur auf die Reihenfolge der Nodes und railway:signal:direction=* achten, um festzustellen, ob das Signal für meinen Nutzer relevant ist oder nicht. Das spart Entwicklungsaufwand und Rechenzeit.

Ich bezweifle, dass die Bahn (und vermutlich ist es im Straßenwesen ähnlich [2]) die Signale mit Richtungswinkel in ihren Datenbanken speichert. Bahnstrecken und Straßen haben eine Kilometrierung (im Straßenbau kenne ich auch den Begriff der Stationierung). Von eine Ursprung aus wird aufsteigend die Entfernung gezählt. Ich brauche also nur speichern, ob das Schild/Signal in Kilometrierungsrichtung oder entgegen oder in beide gilt. KISS!

Klar, die von dir angesprochenen Probleme existieren. Die Lösung lautet bessere Editoren und bessere QA-Tools. JOSM (iD auch?) dreht automatisch alle Vorkommen von forward und backward, left und right in Keys (z.B. maxspeed:forward -> maxspeed:backward), wenn der Way gedreht wird. Es ist egal, welches Tag das ist. Es fehlt nur noch die Unterstützung für ein Drehen der Values. Da sich die JOSM-Entwickler demgegenüber aber ablehnend zeigen, werde ich wohl selbst noch den Patch schreiben müssen. Ebenso müssen die Editoren das Splitten von Ways entweder verweigern oder beim Drehen oder Neuzeichnen von Ways alle Ways herunterladen, die den Node referenzieren. Das ist machbar.

Für dumme Editoren (Fingerzeig in den Javascript-Keller) braucht man wohl QA-Tools, die die Diffs nach entsprechenden gefährlichen Edits durchkämmen und Warnungen ausgeben.

Bitte bedenke, dass railway:signal:direction=* schon 19 303 Mal verwendet wird. traffic_signals:direction=* übrigens nur 9 782 Mal.

Viele Grüße

Michael


[1] Britische Einheiten sind ein großer Schxxx. Man muss sie beim Datenbankimport gesondert behandeln, weil man sie nicht einfach im Stylesheet mit <, > usw. abfragen kann.
[2] Falls überhaupt Datenbanken verwendet werden. Vieles gibt es bestimmt bloß als AutoCAD-DWG-Datei (also als Vektorgrafikzeichnung mit Layern).

Last edited by Nakaner (2015-01-27 15:03:38)


Ein aussagekräftiger Änderungssatzkommentar gehört zum guten Ton.
Moderator im Bereich users: Austria.

Offline

#13 2015-01-27 15:21:28

Seoman
Member
Registered: 2011-07-14
Posts: 61

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

Nakaner wrote:

sonst würden wir heute schon die Signal- oder Ampelrichtung als Relation erfassen, die zwei Nodes referenziert – einen from-Node und einen signal-Node.

Es geht in etwa in diese Richtung ...

OK, da ich es ja nun selbst beschworen habe, muss ich mich wohl doch endlich mal aufraffen, das zusammenzuschreiben. Gibt es eigentlich so etwas wie "ungewollte Selbst-Motivation" ...?  big_smile

Ich will hier nichts Unvollständiges posten, gebt mir daher bitte einen oder zwei Tage - ich weiß nicht, ob ich vor Donnerstag abend dazu kommen werde.


Seoman

Offline

#14 2015-01-27 15:24:40

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,228
Website

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

Seoman wrote:

Gibt es eigentlich so etwas wie "ungewollte Selbst-Motivation" ...?  big_smile

Ich glaube, sowas nennt man Ehrgeiz wink

Gruss
walter

Offline

#15 2015-01-27 15:28:21

Thoschi
Member
Registered: 2013-07-19
Posts: 767

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

Seoman wrote:

Hallo,

Nakaner wrote:

Bei einer Ampel erfasst man:
1. die Richtung, für die sie gilt mit traffic_signals:direction=forward/backward

Das ist ein Tag, der mich schon lange stört. Ich wollte dazu längst mal ein Proposal machen, um es loszuwerden bevor es sich zu sehr verbreitet (die - recht einfache - Idee dazu steht schon, ich schiebe es nur immer wieder vor mir her, daraus ein Proposal zu machen bzw. eine Diskussion anzustoßen).

Der Grund für meine Ablehnung ist folgender: Wir weisen hier einem node eine Richtung zu, das ist höchst unlogisch und hat auch Konsequenzen.

traffic_signals:direction=forward/backward funktioniert nur so lange, wie die Wegsegmente neben dem node in dieselbe Richtung weisen. An der Position der Ampel kann jedoch schnell mal ein Weg gesplittet und/oder umgedreht werden. Als Folge habe ich z.B. einen Ampel-Knoten zwischen zwei Wegen, die beide von der Ampel wegzeigen
--> traffic_signals:direction=forward/backward ist nicht mehr auswertbar!

Seoman

Also ich habe den Tag intensiv genutzt. Sicher kann das schnell von einem unwissenden umgedreht werden, aber wie bei vielen Tags nutzen (auch bei Abbiegebeschränkungen), geht schnell etwas schief, wenn man an Kreuzungen was ändert. Ich sehe hier genauso viel Pflegeaufwand, wie bei allen anderen Tags bei Kreuzungen und Einmündungen die Richtungsabhängig sind (u.a. turn:lanes, change:lanes, Abbiegebeschränkungen etc.).

Offline

#16 2015-01-27 15:48:26

seawolff
Member
From: Kiel
Registered: 2008-08-29
Posts: 426

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

Jojo4u wrote:
Seoman wrote:
Nakaner wrote:

Bei einer Ampel erfasst man:
1. die Richtung, für die sie gilt mit traffic_signals:direction=forward/backward

Das ist ein Tag, der mich schon lange stört. Ich wollte dazu längst mal ein Proposal machen, um es loszuwerden bevor es sich zu sehr verbreitet.

Der Grund für meine Ablehnung ist folgender: Wir weisen hier einem node eine Richtung zu, das ist höchst unlogisch und hat auch Konsequenzen.

traffic_signals:direction=forward/backward funktioniert nur so lange, wie die Wegsegmente neben dem node in dieselbe Richtung weisen. An der Position der Ampel kann jedoch schnell mal ein Weg gesplittet und/oder umgedreht werden. Als Folge habe ich z.B. einen Ampel-Knoten zwischen zwei Wegen, die beide von der Ampel wegzeigen
--> traffic_signals:direction=forward/backward ist nicht mehr auswertbar!

Es könnte auch sein, dass sich die Straße am Ampelknoten verzweigt. Dann wäre "traffic_signals:direction" ebenfalls undefiniert.

Danke, das brennt mir auch auf den Nägeln. Was ist deine einfache Lösung?

Man könnte den durch Ampeln geregelten Bereich als Fläche erfassen (entlang der Haltelinien mit Fortsetzung auf der Gegenfahrbahn).
Eine Ampel würde nur für die ins innere führende Fahrtrichtung gelten.
Eine solche Fläche wäre mit jedem Editor zu erstellen und durch den Mapper einfach zu prüfen (im Gegensatz zu Relations- oder "traffic_signals:direction"-basierten Daten).
Man würde damit nebenbei die Zusammengehörigkeit der Ampeln erfassen und Aussagen zur Zahl der Ampelkreuzungen/-einmündungen in einer Gemeinde ermöglichen.

Offline

#17 2015-01-27 15:52:00

Thoschi
Member
Registered: 2013-07-19
Posts: 767

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

seawolff wrote:

Es könnte auch sein, dass sich die Straße am Ampelknoten verzweigt. Dann wäre "traffic_signals:direction" ebenfalls undefiniert.

Das verstehe ich nicht. Ich setze traffic_signals als Node auf den highway (wo die Ampel bzw. die Haltelinie ist)- NICHT auf den Node der Kreuzung! Und dann habe ich bezgl. forward/backward keine Zweideutigkeiten mehr.

Offline

#18 2015-01-27 16:07:43

Jojo4u
Member
Registered: 2014-08-03
Posts: 1,090

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

Der highway der

Thoschi wrote:
seawolff wrote:

Es könnte auch sein, dass sich die Straße am Ampelknoten verzweigt. Dann wäre "traffic_signals:direction" ebenfalls undefiniert.

Das verstehe ich nicht. Ich setze traffic_signals als Node auf den highway (wo die Ampel bzw. die Haltelinie ist)- NICHT auf den Node der Kreuzung! Und dann habe ich bezgl. forward/backward keine Zweideutigkeiten mehr.

Der highway der zur Kreuzung hinführt ist durch change:lanes/turn:lanes unter Umständen stark fragmentiert. Jetzt soll man auf keinen Fall ein highway=traffic_signals auf einen Node zwischen zwei Ways setzen?

Offline

#19 2015-01-27 16:35:20

geri-oc
Member
From: Sachsen
Registered: 2011-03-21
Posts: 4,231
Website

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

Jojo4u wrote:

...

Der highway der zur Kreuzung hinführt ist durch change:lanes/turn:lanes unter Umständen stark fragmentiert. ...

... und manche lanes haben noch eigene "Ampeln".

Offline

#20 2015-01-27 19:00:09

hurdygurdyman
Member
Registered: 2009-12-10
Posts: 2,847

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

Nach dem Überfliegen des Proposals komme ich zu dem Schluss, dass die relationale Erfassung vom Ampeln auf Spurebene mit deren Ampelphasen vollkommen überzogen und realitätsfremd ist. Ich kenne keine Ampel - und dazu gehören auch temporäre Baustellenampeln - die nicht mit irgendwelchen Sensoren ausgestattet ist, welche das Verkehrsaufkommen erfassen und die Ampalsteuerung davon abhängig variabel steuern. Allein vor diesem Hintergrund ist das Schema Blödsinn überflüssig.
Wenn ich einen Router programmieren würde und könnte, der zusätzliche Kosten für eine Ampel als Malus in die Berechnung einbezieht, wäre das ein wie auch immer pauschalierter Wert für die ganze Kreuzung vielleicht noch unter Berücksichtigung der verkehrlichen Bedeutung. Somit reicht ein als Ampel getaggter node am Kreuzungspunkt, wenn alle ankommenden ways betroffen sind und sonst ein entsprechender node auf dem oder den ankommenden ways mit Ampel.

Edit:
Viel Spaß damit bei Anwendung des Proposals
auch bei diesem Beispiel

Last edited by hurdygurdyman (2015-01-27 19:18:18)


Gruß Michael (hurdygurdyman)
Ich mappe für Menschen, die Karten verwenden, welche aus OSM-Daten gerendert wurden tongue http://de.wikipedia.org/wiki/KISS-Prinzip cool

Offline

#21 2015-01-27 19:40:01

geri-oc
Member
From: Sachsen
Registered: 2011-03-21
Posts: 4,231
Website

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

Sollten Daten nicht einmal die Wirklichkeit wiedergeben?
Jetzt geht OSM dahin eine Straßen - Routing - Anwendung zu werden - alles wird "abstrahiert".

Offline

#22 2015-01-27 22:01:18

furban
Member
From: Bad Homburg
Registered: 2012-02-11
Posts: 64

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

Das finde ich ja schon lustig. Nach ein paar Tagen Pause schaue ich hier mal wieder rein und finde schon gleich wieder ein sehr schönes Beispiel warum man Spuren im Kreuzungsbereich trennen sollte. Damit wäre das Problem mit der Richtung erledigt. Die Ampel kommt genau da hin wo sie steht. Nämlich an der Haltelinie und die Richtung ist auch klar weil es halt eine definierte Spur für die Richtung gibt. Es könnte so einfach sein und mir fehlen noch immer echte Argumente die gegen die Spurtrennung sprechen.
Auf diese Weise kann man sich eine Menge backward/forward Tags sparen und somit gibt es auch damit keine Probleme.

Offline

#23 2015-01-28 06:44:24

hurdygurdyman
Member
Registered: 2009-12-10
Posts: 2,847

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

geri-oc wrote:

Sollten Daten nicht einmal die Wirklichkeit wiedergeben?
Jetzt geht OSM dahin eine Straßen - Routing - Anwendung zu werden - alles wird "abstrahiert".

Die Wirklichkeit wäre eine Ampel in 3D, die an einem Mast oder einer Traverse über oder neben der Straße befestigt ist. roll Jede Art von Kartographie ist eine Abstraktion und Generalisierung.
Und:
OSM heißt immer noch OpenStreetMap. Daraus leite ich ab, dass der ursprüngliche Zweck der Datenerfassung darin lag und für mich auch noch liegt, diese zur Orientierung bei der Straßennutzung zu verwenden. Das ist nun einmal routing.
Wenn es jemandem darum geht, die Realität möglichst original nachzubilden, sollte er sich dem Modellbau widmen.

Last edited by hurdygurdyman (2015-01-28 08:05:39)


Gruß Michael (hurdygurdyman)
Ich mappe für Menschen, die Karten verwenden, welche aus OSM-Daten gerendert wurden tongue http://de.wikipedia.org/wiki/KISS-Prinzip cool

Offline

#24 2015-01-28 07:14:32

hurdygurdyman
Member
Registered: 2009-12-10
Posts: 2,847

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

furban wrote:

Das finde ich ja schon lustig. Nach ein paar Tagen Pause schaue ich hier mal wieder rein und finde schon gleich wieder ein sehr schönes Beispiel warum man Spuren im Kreuzungsbereich trennen sollte. Damit wäre das Problem mit der Richtung erledigt. Die Ampel kommt genau da hin wo sie steht. Nämlich an der Haltelinie und die Richtung ist auch klar weil es halt eine definierte Spur für die Richtung gibt. Es könnte so einfach sein und mir fehlen noch immer echte Argumente die gegen die Spurtrennung sprechen.
Auf diese Weise kann man sich eine Menge backward/forward Tags sparen und somit gibt es auch damit keine Probleme.

An verschiedenen Stellen wurde versucht, auch dir die Konsequenzen und Probleme, welche die getrennte Erfassung von Spuren mit sich bringt, zu erläutern. Ich werde das nicht wiederholen.
Übrigens habe ich noch keine Ampel gesehen, die mitten auf der Spur steht....
Wie wäre es, wenn du alle deine Argumente, die für die Spurtrennung sprechen, mal zusammenfasst und dabei auch berücksichtigst, welche Nachteile dies mit sich bringt und welche neuen Probleme dadurch entstehen. Geeignet dazu und vorgesehen wäre ein Proposal, um deine Ideen und Lösungsansätze konstruktiv der Community nahe zu bringen, damit diese darüber befinden und entscheiden kann. Für das Etablierte und von dir kritisierte lanes-Schema gibt es das.

Last edited by hurdygurdyman (2015-01-28 08:06:32)


Gruß Michael (hurdygurdyman)
Ich mappe für Menschen, die Karten verwenden, welche aus OSM-Daten gerendert wurden tongue http://de.wikipedia.org/wiki/KISS-Prinzip cool

Offline

#25 2015-01-28 07:38:58

Thoschi
Member
Registered: 2013-07-19
Posts: 767

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

Jojo4u wrote:

Der highway der

Thoschi wrote:
seawolff wrote:

Es könnte auch sein, dass sich die Straße am Ampelknoten verzweigt. Dann wäre "traffic_signals:direction" ebenfalls undefiniert.

Das verstehe ich nicht. Ich setze traffic_signals als Node auf den highway (wo die Ampel bzw. die Haltelinie ist)- NICHT auf den Node der Kreuzung! Und dann habe ich bezgl. forward/backward keine Zweideutigkeiten mehr.

Der highway der zur Kreuzung hinführt ist durch change:lanes/turn:lanes unter Umständen stark fragmentiert. Jetzt soll man auf keinen Fall ein highway=traffic_signals auf einen Node zwischen zwei Ways setzen?

Zwischen zwei ways ist kein Problem, sofern es dieser Node nicht der Kreuzungspunkt von zwei Straßen (Achtung: Straße ist nicht identisch mit way!) ist.
Mir ist bisher noch keine Ampel untergekommen, die nur in der Mitte der Straße ist. Eine reine Linksabbiegerampel schon, an eine reine Rechtsabbiegerampel kann man sicher auch denken. Es ist zwar klar, dass die Realität mehr Möglichkeiten verbirgt als wir in der Abstraktion denken, trotzdem kommt man mit traffic_signals:direction=forward/backward in 99 % der Fälle hin. Wo es reine Linkabbiegerspuren gab, war bei mir auch eine bauliche Trennung der Gegenfahrbahn, so dass man die Ampel auf die "Stückchen" eigenen Way der Linkabbiegerspur setzen konnte.

Aber um auf den Thread zurück zu kommen: Abbiegerelationen und Grünphasen halte ich für übertrieben!

Last edited by Thoschi (2015-01-28 07:39:49)

Offline

Board footer

Powered by FluxBB