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

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.

Die Wirklichkeit wäre eine Ampel in 3D, die an einem Mast oder einer Traverse über oder neben der Straße befestigt ist. :roll_eyes: 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.

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.

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!

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.

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.

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_eyes:

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.

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.

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

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.

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!

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

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?

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.

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?

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?

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.