Routenglättung anhand logischer Straßenfolge

[gluap]

@matthias-ms Edit: Pardon, hatte überlesen, dass du ihn wiedereingespielt hast, ja du hast das richtig erkannt - Ich hatte das auch im Edit oben geschrieben, aber der ist vermutlich erst angekommen als du schon geschrieben hast:

Das ist hier mit der Straßennutzung eine Besonderheit: Der Laerer Landweg ist markiert als Brücke+ Embankment auf beiden Seiten mit „bicycle=yes“. (= radfahrer/fußgängerbrücke). Deshalb ziehen wir sie für die Auswertung der Überholabstände nicht in Erwägung (auf dem Radweg kann man ja nicht überholt werden). Dass die Straße dann bei der Straßennutzungskarte nicht auffällt ist ein Seiteneffekt davon. Die Openstreetmap ist also richtig - das Problem ist, dass wir die Straße nicht für Überholabstände benutzen - Und den Abschnitt deshalb (seiteneffekt) nicht für die Straßennutzung in Erwägung ziehen. Wäre nicht (so) negativ aufgefallen, wenn nicht gleichzeitig die Umgehungsstraße drunter wäre, die man (vermutlich) eigentlich nicht benutzen darf, aber die in der OSM (zumindest in der Version die derzeit im Portal geladen ist) derzeit benutzbar ist, und die dann „die nächste Straße“ am Track ist. Also: Coolen Sonderfall gefunden.

[matthias-ms]

hatte 4 von 4 gelöscht und einen wieder hochgeladen, das ist der am Kanal lang und über die Fußgängerbrücke, die Teil vom NRW Radwegenetzes ist:

MS521.pdf

das dicke graue ist die Umgehungsstraße:

[gluap]

@matthias-ms schau noch mal meine letze Antwort an (falls nicht geschehen)- Hab sie noch mal editiert. Du hast den Effekt richtig erkannt. Ich habs mal aufgeschrieben, dass wir da für die Road Usage korrigieren müssen.

Eine Sache die dich sicher noch wundert ist vermutlich, warum so ein langes Stück Umgehungsstraße markiert wird - Das liegt daran, dass wir derzeit einfach das ganze Segment in der OpenStreetmap markieren - Und das Segment Umgehungsstraße ist einfach so lang. Zur Segmentreorganisation gibt es auch schon ideen.

[matthias-ms]

ihr habt gerade meinen Tag gerettet: die Balkontür war schon auf…

Die B51 wird gerade „neu gebaut“, da kann es natürlich sein, das die Beschreibungen noch nicht genau „sitzen“ - das ist vielleicht nur lokales Wissen - die Baumaßnahme ist riesig und wird noch lange dauern…

[gluap]

@mathias-ms danke dir fürs hartnäckig bleiben und testen bis wir das Problem identifizieren konnten!

[HortusNanum]

Da das im Ursprungspost geschilderte Problem offenbar immer noch aktuell ist, hole ich diesen alten Thread mal wieder vor.
Die Fehlzuordnung von Tracks und Überholdaten zu parallel- oder Stichstraßen sorgt hier für ein ziemliches „Rauschen“ auf den Wald - und Feldwegen rund um eine Bundesstraße. Da auf diesen kein Autoverkehr erlaubt ist (und auch nicht stattfindet), sorgt die rote Färbung dieser Wege regelmäßig für Irritationen und nährt damit natürlich auch Zweifel an Messmethode und -daten.

Ich habe darauf mal ein bisschen herumgegooglet und geschaut, wie andere Projekte das lösen. Neben einigen kommerziellen (zum Teil KI-gestützten) Produkten habe ich das hier gefunden: Snapping GPS tracks to Roads using PyQGIS and OSRM – Spatial Thoughts
Könnte man das vielleicht im Portal implementieren?

[gluap]

@HortusNatum: Ich sehe zwei Fragestellungen:

Müsste die Trackauswertung erkennen, dass es unplausibel ist, dass die Punktzuordung annimmt, dass ein Track in einen Stichweg hereinfährt?

z.B. 90° zur Bewegungsrichtung abzweigend wie hier bei der Befahrungshäufigkeit?

Müsste die Trackauswertung erkennen, dass ein Track auf einem parallel zur Landstraße verlaufenden Waldweg unplausibel ist?

Ich vermute du suchst nach einer Lösung für Situationen wie hier

Der parallel (weiter rechts) verlaufende Waldweg ist laut OSM für autos nicht gesperrt - man könnte also dort plausibel überholt werden, was die OpenStreetmap angeht:

(wtf hat Sir Lancelot sich dabei gedacht einen grade 4 track als class:bicycle=1 einzutragen? nichtmal mit „mtb“ geprefixt, das macht doch am ende für alle das routing kaputt.)

Daraus ergibt sich für mich die Frage:

• Wie kann das überhaupt erkannt werden, wenn laut OpenStreetMap beide Wege autozugelassen sind?
• Muss das auch erkannt werden, wenn kein Überholvorgang gedrückt wird?
• Wie viel GPS-Drift muss dabei ausgeglichen werden?

Derzeit importieren wir ja ins Portal bereits nur Wege, die auch Autozugelassen sind (davon wollen wir eigentlich weg, weil die besten Radstrecken oft autoverboten sind).

[gluap]

Ich hab mir das OSRM mal angeschaut - Für Snapping wäre das prima, allerdings braucht man für Deutschland vermutlich so 32 Gigabyte RAM oder mehr - die meisten Portale laufen so auf ~2 - 4 gigabyte ram: Disk and Memory Requirements · Issue #5265 · Project-OSRM/osrm-backend · GitHub. Mal sehen ob wir die API auf fair use basis benutzen dürfen.

[HortusNanum]

Beide Fragen kann ich nur insofern beantworten, als dass das Routensnapping eindeutig erkennen sollte, wo ich gefahren bin und wo nicht, um damit die Überholvorgänge den richtigen Straßen zuzuordnen. Momentan springt die Zuordnung ziemlich erratisch:

Der Überholvorgang wird einer Seitenstraße zugeordet, die ich auf meiner Route nicht mal erreichen könnte, da ein Bach dazwischen liegt. Hier müsste das Snapping erkennen, dass ich der Hauptstraße gefolgt bin.

Das resultierende Problem sieht man hier:

Die Nebenstraßen (hier ein Parkplatz am Ende einer Sackgasse) sind eingefärbt, obwohl es dort gar keine Fahrten gab.

Grundsätzlich kann die Plausibilität einer Befahrung wohl nur im Kontext des Tracks und nicht des Überholvorgangs selbst beurteilt werden.

Wenn ich den Track bei Strava hochlade, wird korrekt erkannt, dass ich die Hauptstraße nicht verlassen habe. Daher die Idee mal über den Tellerrand zu schauen.Wo ich das schreibe fällt mir ein: Vielleicht könnte man die Leute von https://runalyze.com/ mal fragen wie die das machen? Die benutzen auch die OSM.

Für Snapping wäre das prima, allerdings braucht man für Deutschland vermutlich so 32 Gigabyte RAM oder mehr - die meisten Portale laufen so auf ~2 - 4 gigabyte ram

Hm, sollte sich das bestätigen und das mit der Fair-Use API klappt nicht, vielleicht könnte man dann einen zentralen OBS Snapping-Server bereitstellen, den die anderen Portale benutzen können? So bräuchte man nur einen so potenten Server.

[gluap]

@HortusNanum Ich denke du hast recht, und die, die das machen, verwenden einen Routingalgorithmus mit dem Ziel, eine möglichst nahe gelegene befahrbare Strecke zu finden. Der Ansatz das OSRM zu verwenden könnte dahingehend eine mögliche Technik sein. Unsere Straßendaten im Portal sind derzeit nicht für den Plausi-Check in der Form geeignet, weil wir nicht alle Fahrradbefahrbaren Wege drin haben.

Eine „Plausible“ Route zu finden ist sicher ein technisch lösbares Problem - Und je mehr Arbeit man investiert, desto mehr „Plausibel“ kann man auch machen. Das ist aber auch kein einfaches Problem.

z. B. muss man sich folgende Fragen beantworten (und schlimmer: programmieren):

• Wenn die Route plausibel sein muss, wo darf das Fahrrad lang fahren?
  • Nur auf Fahrradbefahrbaren Wegen?
  • Was passiert dann wenn die Daten falsch sind, wird das Snapping dann im zweifelsfall einen 5km umweg fahren weil ein Weg durch eine Waldstück nicht befahrbar ist oder der Fahrer eine Fußweg-Abkürzung genutzt hat?
  • Was passiert mit Überholvorgängen während solcher großräumigen Snappingvorgänge?
• Wo dürfen Überholvorgänge auftauchen?
  • Nur auf Autobefahrbaren Wegen?
    • Wie wird das Snapping dann geregelt - kürzestes Straßensegment um dem Überholvorgang gerecht zu werden und dann wieder Straßenbegleitender Radweg?
  • Auf allen Wegen, weil die Karte falsch sein könnte?
    • Wenn auf allen Wegen: Mappt man das Rad dann normalerweise auf die Straße selbst oder den Straßenbegleiteten Radweg? Oder „Wo es näher dran ist“? Nimmt man an, dass man dazwischen beliebig wechseln kann auch wenn es zwei polygone sind?
    • Wie reagieren die Nutzer der Karte, wenn auf Radwegen massig Überholvorgänge streuen?
    • Dieses Problem ist einer der Gründe, aus denen wir derzeit nur „Autobefahrbar“ importieren. So können immerhin Überholvorgängen nur auf Autostraßen snappen.

Das sind alles Fragen die man sich für eine running map oder einfaches Tracknachzeichnen nicht beantworten muss, weil es in diesen Fällen immer egal ist, ob der Läufer oder das Rad auf der Straße oder einem Fußweg unterwegs ist, man kann einfach alles routen, was konsistent ist, ohne sich Gedanken zu machen.

Unsere Erfahrung in Darmstadt ist, dass es bisher wenige Kommentare für die occasional mismapped Straße gab. z.B. hier sehen wir das in unserer Karte, die Überholevents in den Seitenstraßen sind alle so entstanden.

[HortusNanum]

Ich bin nicht sicher, ob es zielführend ist, sich an die exostischsten Edge-Cases zu halten. Natürlich wird man irgendwann an einen Punkt kommen, an dem diese relevant werden, aber der ist noch weit weg.

Ich stelle mir das so vor:
Beim Upload des Tracks wird dieser an den vorhandenen Karten ausgerichtet und an die vorhandenen Wege angeglichen. Dabei hilft ein Routing-Algorithmus wie z.B. OSRM. Die GPS-Koordinaten der Überhol-Events werden dabei wenn nötig auf die „richtige“ Straße verschoben, bzw. dem entsprechenden Straßensegment zugeordnet. In den allermeisten Fällen wird dies bereits eindeutige Ergebnisse liefern, die besser sind als der Status-Quo.

Wenn man wirklich so einen Fall hat, dass eine Autobahn und ein Feldweg parallel verlaufen, der GPS-Track nicht eindeutig ist und auf dem einen Weg ist das Radfahren verboten und auf dem anderen das Autofahren, muss man sich halt für eines entscheiden. Ich könnte mir aber vorstellen, dass die Router das schon berücksichtigen, wenn man ihnen sagt, dass man mit dem Rad unterwegs war. Am Ende kann das vermutlich nur der User entscheiden, der weiß wo er gefahren ist (siehe Feature Request: Manually fix road snapping · Issue #251 · openbikesensor/portal · GitHub).

[gluap]

@HortusNanum
Das ist das Problem, das ist leider keine exotischer Edge case. Neben vielen großen Straßen läuft ein Straßenbegleitender Radweg (respektive freigegebener Fußweg), der auch oft ein eigenes Polygon hat. In all diesen Fällen würden wir Überholevents auf Radwege mappen, wenn der GPS Track nur um 2 Meter Richtung Radweg verschoben ist, und wir so ein OSRM routing benutzen, ohne noch reichlich extra intelligenz reinzustecken. Für die running Map ist es herzlich egal, ob du auf der Straße gelaufen bist oder auf dem Radweg, weil beide parallel laufen. Für OSRM auch, weil meistens beide so getaggt sind, dass sie von Fahrrädern benutzt werden dürfen.

Du kannst gerne mal eine Beispielimplementierung machen, wenn du eine Idee hast wie es einfacher ist als mein Eindruck davon, oder auch mit Worten erklären, wie man die straßenbegleitenden Radwege mit OSRM behandeln könnte.

Ich stimme zu, das kann am ehesten der User fixen - Die Frage ist dann noch, wie viele Prozent der Events falsch gemapped werden und ob die Reduktion beim Rauschen den enormen Aufwand, eine UI für manuelles Tracksnapping zu implementieren rechtfertigt. Meine Vernutung ist: Die Mehrzahl der Nutzer wird ihren OpenBikeSensor am Fahrrad haben, ab und an hochladen aber selten - nie ihre Tracks manuell kuratieren.

Welche Anfragen bekommst du denn gewöhlich bezüglich der falsch gesnappten events?

[opatut]

Hallo Leute,

als nächstes auf meiner Programmierliste steht tatsächlich mal dieser Algorithmus. Dieses OSRM ist ja leider nur so halb was wir wollen, ich fürchte jeder out-of-the-box Algorithmus wird nicht genug fine tuning erlauben für unseren Zweck. Daher wollte ich lieber noch mal die angefangene Logik mit belief chain propagation aufgreifen und aber von vorn bauen, um das ganze schön effizient zu bekommen. Und dann können wir Gewichtungen fine-tunen, wie zum Beispiel:

• Penalty von Straßenwechsel
• Kostenfunktion nach Abstand zur GPS-Koordinate
• Gewichtung nach OSM tags, z. B. an Radwege stärker snappen als an Straßen ohne Fahrraderlaubnis, und auch möglicherweise abhängig vom Vorhandensein von Überholevents oder Abstandsmessungen, sowie Einbahnstraßen-Thematik
• Glättung der GPS-Daten vor Snapping

Ich denke dass ich das mal erstmal offline in ein Jupyter Notebook baue und dann visualisiere, sodass wir gemeinsam rumspielen können. Ich melde mich wenn das Grundgerüst steht, dann könnt ihr alle eure Tracks da rein werfen und mit probieren.

LG Paul

[fietsekapitaen]

Hallo Paul,
Matthias hier, und gleichzeitig hallo Forum - ich bin neu und fahre seit einer Woche mit einem ADFC-OBS in Berlin/Brandenburg herum.

Von den wenigen Überholevents, die ich bisher loggen durfte, sind etliche auf inkorrekt geschnappten Nebenstraßen. Bevor ich mein eigenes Jupyter Notebook fürs reparieren der Tracks baue - hast Du im Nachgang zu diesem Thread noch etwas dazu programmiert?
Viele Grüße,
Matthias

[opatut]

Hallo Matthias und willkommen im Forum.

Ja ich hatte „damals“ was programmiert das so halb fertig war. Das eigentliche Snapping war richtig gut geworden (im Vergleich zu vorher). Ich glaube das ist auf dem Branch lots-of-changes (ich weiß, guter Name) mit drauf…

Dann habe ich versucht das ganze mit dem Binärimport für OBS Lite zu kombinieren, mich leider in details verloren und irgendwie ging die Motivation dann flöten Ich sollte das mal fertig machen. Gut dass ich gerade im ICE sitze und auch noch ein bisschen Urlaub habe

Versprechen mag ich nichts, aber ich schau mal was ich die nächsten Tage davon so „fertig“ bekomme dass wir mal ne neue Version basteln können mit zumindest dem verbesserten Snapping. Wenn du so etwas auch kannst (Daten in Python hin und her schubsen und in ne PostgreSQL werfen) und Lust hast mitzuhelfen schreib mich mal direkt irgendwo an.

LG Paul

[fietsekapitaen]

Moin, also ich habe inzwischen eine fertige Bastellösung für mein Problem. Für Tracks, die allzu schlecht aus dem OBS kommen, erzeuge ich auf map.meurisse.org einen groben GPX-Track, der meiner in echt gefahrenen Route entspricht. In Python erzeuge ich dafür eine Interpolation mit mehreren tausend Punkten entlang dieses Tracks. Daran spiele ich die Überholungsereignisse, indem ich die der aufgezeichneten Position beim Überholungsereignis nächste Position auf dem konstruierten Track finde. Mit den als korrekt angenommenen Zeitstempeln vom ersten Punkt, denen der Überholungsereignisse und dem des letzten Punktes interpoliere ich linear die Positionen, die ich auf dem konstruierten Track zum jeweiligen Zeitpunkt zwischen den festen Ereignissen gehabt haben würde (Annahme: konstante Geschwindigkeit!). Damit kann ich im OBS-Track für jeden Datenpunkt eine korrigierte Position und Geschwindigkeit errechnen. Dieses editierte File lade ich dann wieder hoch, und mein aufgezeichneter Track entspricht meiner nachkonstruierten Route.

Jetzt allerdings laufe ich an einigen Tracks in ein Problem, wo der Snapping-Algorithmus trotzdem auf naheliegende Seitenstraßen ausweicht, hier z.B. bin ich den Lindenring im Bild im Uhrzeigersinn gefahren, aber der Algprithmus schickt mich auf den Zickzackkurs der Parkplatzzufahrten innerhalb des Rings:

Wie kann ich helfen, das zu verbessern?

[fietsekapitaen]

Noch ein Beispiel… ich fahre den uferparallelen Radweg, im Bild die gestrichelte Linie, aber das Portal schnappt mich bei der Vorbeifahrt kurz aufs Ende der Sackgasse, weil das dort eine nahe Straße ist.

Kann das im Import-/Routingalgorithmus geändert werden? Oder könnte in den OSM-Wegen etwas entgegen Standards gesetzt sein, was den Import verwirrt?

[opatut]

Dein Weg im zweiten Post ist wohl dieser hier, der nur mit highway=path markiert ist. Entsprechend der OSM Regeln für Straßenbenutzung ist es in Deutschland nicht erlaubt, auf solchen „Pfaden“ mit KFZ zu fahren.

Es ist ein bisschen schwer zu entscheiden, welche Straßen wir in die Datenbank aufnehmen. Uns interessiert zwar langfristig auch die Nutzung von KFZ-freien Strecken, aber ein Überholmanöver sollte dort niemals stattfinden. Daher haben wir uns mal dafür entschieden, diese Abschnitte gar nicht erst zu beachten. Das ist falsch für die Straßennutzungsfolge, aber richtig für die Überholabstandstatistik. Insbesondere war die Entscheidung auch dazu da, dass straßenbegleitende Radwege ignoriert werden, sodass eventuell vorhandene Überholabstände auch der Straße zugeordnet werden, und nicht die Straße und der Radweg um die Messung „konkurrieren“.

Mit dem neuen Snapping-Algorithmus in 0.9.0 habe ich die Möglichkeit geschaffen, in Zukunft besser und genauer auf diese Unterschiede einzugehen, und evtl. abhängig von der Anwesenheit von bestätigten Überholvorgängen eine Routenführung auf Straßenzügen mit KFZ-Verkehr zu bevorzugen, und in Abwesenheit solcher Abstandsmessung die KFZ-freien Routen zu bevorzugen. Das ging mit dem alten Algorithmus nicht, ist aber jetzt in Planung. Da das eine Erweiterung des Straßenimports bedeuten würde, ist das aber erstmal in 0.9.0 nicht mit drin, das wäre mir zu viel auf einmal gewesen

[opatut]

@fietsekapitaen

Wie kann ich helfen, das zu verbessern?

Das mit dem Lindenring hab ich auch mal angeschaut, sieht so aus als sei das eine Einbahnstraße, die Radfahrer:innen rückwärts befahren dürfen (OSM). Ich glaube der Importer beachtet das oneway:bicycle=no aber nicht.

So ein Bericht hier hilft natürlich schon Wenn du Lust hast kannst du auch versuchen, dem Importer das Beachten der oneway:bicycle tags beizubringen.

LG Paul

Edit: Ach Quatsch, gleicher Fall wie davor, das ist Absicht. Du wirst ja in einer rückwärts befahrenen Einbahnstraße nicht von einem KFZ überholt werden. Also auch da warten wir lieber darauf, dass der Snapping Algorithmus unterscheiden kann zwischen KFZ-freien Straßen und solchen mit KFZ.

[fietsekapitaen]

Ok, Absicht, aber… dann passt die Straßenbenutzungsstatistik nicht, oder? Sollte nicht die Route akkurat sein, schon alleine um Zweifel am System nicht aufkommen zu lassen?