You are not logged in.

#26 2015-01-28 12:30:54

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

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

hurdygurdyman wrote:
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.

Da hatte ich aber OpenStreetmap in der Tat anders verstanden. Ich dachte immer Routing eher eins von vielen Anwendungsmöglichkeiten und es geht hauptsächlich darum möglichst viele nützliche Daten in der Karte unterzubringen. Dazu gehört dann natürlich auch das diese Daten möglichst in der Karte dargestellt werden und das auch möglichst nah daran wie es in der Realität aussieht. Wenn es nur um Routing geht, können wir uns Gebäude, Bäume, Parkbänke, Doggingstations usw ja schenken. Dann reicht es wirklich ein paar Linien durch die Gegend zu ziehen und die dann mit 30 Tags vollzupumpen die dann irgendeine Routingsoftware hoffentlich verarbeiten kann.
Irgendwo habe ich mal gelesen "Wie mappen was wir sehen" und ich sehe eine ganze Menge was in der OSM Karte noch nicht sichtbar ist. Z.B. Verkehrsinseln, Sperrflächen und halt auch Ampeln die nicht dort stehen wo sie in Realität stehen und das wird man auch mit den schönsten Tags nicht schaffen darzustellen.

Offline

#27 2015-01-28 13:03:32

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

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

hurdygurdyman wrote:

auch dir die Konsequenzen und Probleme, welche die getrennte Erfassung von Spuren mit sich bringt, zu erläutern.

Ein paar Versuche gab es aber leider hat mich davon nichts überzeugen könne. Alles war bisher widerlegbar.
Ich bin darüber auch selbst verwundert, da die Befürworter einer Spurtrennung ja wirklich selten zu sein scheinen und ich deshalb auch erwartet hätte das es dafür einschlägige Gründe gibt.
Aber das weicht so langsam doch etwas zu viel vom Thema hier ab.

Toschi wrote:

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.

Na so ein Glück. Dank baulicher Trennung konnte die Spur aufgetrennt werden und das ganze vernünftig getagt werden.
Soll ich vielleicht demnächst mit ein paar Backsteinen und einem Eimer Speis los ziehen und erst mal ein kleines Mäuerchen auf die durchgezogene Linie bauen damit ich dann auch die Spuren trennen kann roll

So ich hau mir jetzt auf die Finger und höre auf. Kann mir schon vorstellen das es nervt wenn man zu 100% einer anderen Meinung ist wie das wohl die Meisten sind.
Leider geht meine Engagement (noch) nicht so weit das ich das versuchen werden die ganze Community aufzumischen mit irgendwelchen Proposals

Ich habe übrigens schon munter angefangen Ampeln von der Kreuzungsmitte auf die Fahrspuren zu verlagern und dann mangels Spurtrennung mit traffic_signals:direction zu taggen.
Aber das lasse ich dann wohl auch erst mal wieder bleiben.  Scheint ja auch nicht wirklich beliebt zu sein diese Lösung.

hurdygurdyman wrote:

Für das Etablierte und von dir kritisierte lanes-Schema gibt es das.

Eigentlich habe ich auch nichts gegen das lanes Schema. Ich mag nur forward/backward und direction in allen Varianten nicht. Ich würde das lieber mit entsprechenden Spuren darstellen wo es sinnvoll ist, was auch nicht immer der Fall ist. Aber forward/backward  wird aus meiner Sicht viel zu häufig verwendet und sorgt nicht gerade für Übersichtlichkeit.

.. und auch ich verwende OSM natürlich gerne fürs Routing und OSMAND kann halt mit forward/backward nicht umgehen. Ist also auch ein Stück weit eigennutzen dabei.

Offline

#28 2015-01-28 13:47:37

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

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

furban wrote:
hurdygurdyman wrote:

auch dir die Konsequenzen und Probleme, welche die getrennte Erfassung von Spuren mit sich bringt, zu erläutern.

Ein paar Versuche gab es aber leider hat mich davon nichts überzeugen könne. Alles war bisher widerlegbar.

Naja, sieh es einfach demokratisch, Du hast mit Deinen Argumenten ja auch niemanden überzeugen können.

furban wrote:

Ich habe übrigens schon munter angefangen Ampeln von der Kreuzungsmitte auf die Fahrspuren zu verlagern und dann mangels Spurtrennung mit traffic_signals:direction zu taggen.
Aber das lasse ich dann wohl auch erst mal wieder bleiben.  Scheint ja auch nicht wirklich beliebt zu sein diese Lösung.

Ich habe nirgends gesehen, dass es unbeliebt ist. Und unbeliebt heißt nicht, dass man das nicht so taggen darf/soll, solange es im Wiki steht und nicht auf gemeinschaftlichem Wege rausgeworfen wird, kann man es so taggen. Ich habe mich damit angefreundet und nutze traffic_signals:direction ausschließlich. Immerhin kann man so auch an Kreuzungen Ampeln taggen, an denen es unterschiedliche Querungsmöglichkeiten für Fußgänger gibt. Es gibt ja auch Einmündungen, an denen Fußgänger nicht queren dürfen.

furban wrote:

.. und auch ich verwende OSM natürlich gerne fürs Routing und OSMAND kann halt mit forward/backward nicht umgehen. Ist also auch ein Stück weit eigennutzen dabei.

NOCH nicht!, man kann dies ja bei OSM anregen.
Es kann nicht sein, dass wir die Karte für eine bestimmte Software mappen. Der eine Router wertet es so aus, der andere so. Nur weil ich OSMAnd nutze, kann ich nicht für mich beanspruchen, nur mein Tagging ist korrekt!

Offline

#29 2015-01-28 14:18:08

geri-oc
Member
From: Sachsen
Registered: 2011-03-21
Posts: 5,055
Website

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

Thoschi wrote:

...
Es kann nicht sein, dass wir die Karte für eine bestimmte Software mappen. Der eine Router wertet es so aus, der andere so. Nur weil ich OSMAnd nutze, kann ich nicht für mich beanspruchen, nur mein Tagging ist korrekt!
...

genau das wird aber gemacht, indem alles an eine "Linie" (way) getaggt wird (weil parallele way Navis "stören" - wegen gps- Ungenauigkeit)

Offline

#30 2015-01-28 14:27:31

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

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

Thoschi wrote:

NOCH nicht!, man kann dies ja bei OSM anregen.
Es kann nicht sein, dass wir die Karte für eine bestimmte Software mappen. Der eine Router wertet es so aus, der andere so. Nur weil ich OSMAnd nutze, kann ich nicht für mich beanspruchen, nur mein Tagging ist korrekt!

Das hatte ich schon vor zwei Jahren dort nachgefragt. Da ging es noch um maxspeed:forward was auch nicht unterstützt wird.
Das war die Antwort

-> Actually not yet, there limitations to detect what is forward and backward internally. But we are working on it. VIctor

Auch mehrere Nachfragen, nicht nur von mir, kam keine aktuellere Antwort mehr. Das Problem ist weiterhin aktuell. Das ist ja auch ein Grund warum ich mich frage ob das forward/backward so eine ideale Lösung ist. Mindestens OSMAND, also die aus meiner Sicht beste OSM Routingsoftware, kann damit nicht umgehen. Können es dann Andere? Kann es Scobbler als meine persönliche Nummer 2. Oder gibt es da noch eine Software die ich nicht kenne?

Offline

#31 2015-01-28 14:43:07

Nadjita
Member
From: Erding
Registered: 2013-07-12
Posts: 474

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

Wenn forward und backward nicht ausgewertet werden, impliziert das vermutlich auch, dass left/right nicht ausgewertet wird, da ohne Wissen, in welche Richtung man fährt, ja unmöglich auszuwerten. Durchaus ein größeres Problem, aber wohl eines, das gelöst wird…

Offline

#32 2015-01-28 14:47:35

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

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

Nadjita wrote:

Wenn forward und backward nicht ausgewertet werden, impliziert das vermutlich auch, dass left/right nicht ausgewertet wird, da ohne Wissen, in welche Richtung man fährt, ja unmöglich auszuwerten. Durchaus ein größeres Problem, aber wohl eines, das gelöst wird…

Also
turn:lanes=left|through
zeigt OSMAND korrekt an. Nur mit
turn:lanes:forward=left|through
kann die Software nicht umgehen.
Wenn dann das Problem seit zwei Jahren nicht gelöst wurde scheint es ja so einfach auch nicht zu sein.

Offline

#33 2015-01-28 14:49:32

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

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

geri-oc wrote:
Thoschi wrote:

...
Es kann nicht sein, dass wir die Karte für eine bestimmte Software mappen. Der eine Router wertet es so aus, der andere so. Nur weil ich OSMAnd nutze, kann ich nicht für mich beanspruchen, nur mein Tagging ist korrekt!
...

genau das wird aber gemacht, indem alles an eine "Linie" (way) getaggt wird (weil parallele way Navis "stören" - wegen gps- Ungenauigkeit)

Jetzt habe ich ein Verständnisproblem. Ich vermute Du beziehst Dich auf sidewalk/cycleway etc.? Wenn es keine bauliche Trennung gibt, gibt es doch auch gar keinen Grund für einen parallelen Weg, das macht keinen Sinn, in der Realität sind dies ja auch keine parallelen Weg, sondern ein Weg, der nur unterschiedlich ausgebaut und beschildert ist. Oder habe ich Deine Aussage jetzt in den falschen Hals bekommen?

Offline

#34 2015-01-28 15:10:52

geri-oc
Member
From: Sachsen
Registered: 2011-03-21
Posts: 5,055
Website

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

Wir mappen eine 30 m breite Fläche als einen way - mit hw=*, lanes=*, cyleway=both, sidewalk=left/right, maxspeed=* und eventuell noch forward=*, surface=*, smoothness*, width=*, access=*

Ist so etwas noch sinnvoll auswertbar?

Offline

#35 2015-01-28 15:16:20

JohnDoe23
Member
Registered: 2013-10-11
Posts: 422

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

furban wrote:

Auch mehrere Nachfragen, nicht nur von mir, kam keine aktuellere Antwort mehr. Das Problem ist weiterhin aktuell. Das ist ja auch ein Grund warum ich mich frage ob das forward/backward so eine ideale Lösung ist. Mindestens OSMAND, also die aus meiner Sicht beste OSM Routingsoftware, kann damit nicht umgehen. Können es dann Andere? Kann es Scobbler als meine persönliche Nummer 2. Oder gibt es da noch eine Software die ich nicht kenne?

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.

Offline

#36 2015-01-28 15:25:31

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

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

geri-oc wrote:

Wir mappen eine 30 m breite Fläche als einen way - mit hw=*, lanes=*, cyleway=both, sidewalk=left/right, maxspeed=* und eventuell noch forward=*, surface=*, smoothness*, width=*, access=*

Ist so etwas noch sinnvoll auswertbar?

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

Offline

#37 2015-01-28 15:55:35

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

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

geri-oc wrote:

Wir mappen eine 30 m breite Fläche als einen way - mit hw=*, lanes=*, cyleway=both, sidewalk=left/right, maxspeed=* und eventuell noch forward=*, surface=*, smoothness*, width=*, access=*

Ist so etwas noch sinnvoll auswertbar?

Ja.


Mapper aus dem Münsterland.

Offline

#38 2015-01-28 15:56:53

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

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

Thoschi wrote:
geri-oc wrote:

Wir mappen eine 30 m breite Fläche als einen way - mit hw=*, lanes=*, cyleway=both, sidewalk=left/right, maxspeed=* und eventuell noch forward=*, surface=*, smoothness*, width=*, access=*

Ist so etwas noch sinnvoll auswertbar?

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

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?

Offline

#39 2015-01-28 19:55:15

geri-oc
Member
From: Sachsen
Registered: 2011-03-21
Posts: 5,055
Website

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

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

Offline

#40 2015-01-28 21:38:36

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

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

JohnDoe23 wrote:

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

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.

Offline

#41 2015-02-02 19:35:14

lukasschaus
Member
Registered: 2015-02-02
Posts: 2

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

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/Prop … ic_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

Offline

#42 2015-02-02 19:55:41

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

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

Hallo Lukas,

lukasschaus wrote:

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.

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.

lukasschaus wrote:

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.

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. :-)

Viele Grüße

Michael


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

#43 2015-02-02 20:24:57

Thomas8122
Member
From: Sachsen
Registered: 2012-04-15
Posts: 1,073

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

geri-oc wrote:

Warum haben 3-4 Mapper entschieden, dass eine Doppellinie nicht mehr baulicher Trennung entspricht?

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

Offline

#44 2015-02-09 15:33:59

lukasschaus
Member
Registered: 2015-02-02
Posts: 2

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

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/Prop … als#Voting

Vielen Dank

Offline

#45 2015-02-09 18:45:13

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

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

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.

Offline

#46 2015-02-09 19:20:46

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

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

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

Last edited by Thoschi (2015-02-09 19:24:15)

Offline

#47 2015-02-09 19:31:24

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

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

Thoschi wrote:

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 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. :-)

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


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

#48 2015-02-09 19:35:37

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

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

Nakaner wrote:

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. :-)

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

Offline

#49 2015-02-09 19:46:17

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

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

Thoschi wrote:

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.


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

#50 2015-02-09 20:03:57

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

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

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.

Offline

Board footer

Powered by FluxBB