Routenglättung anhand logischer Straßenfolge

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

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…

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

1 „Gefällt mir“

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?

@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?
image

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

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.

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:

image

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:

image

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.

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

1 „Gefällt mir“

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

@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?

1 „Gefällt mir“

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

7 „Gefällt mir“