Routenglättung anhand logischer Straßenfolge

[opatut]

Hallo zusammen, insbesondere @florian

Ich starte mal mit einem Bild

Wie man sieht, werden meine Überholmanöver fleißig an die Seitenstraßen annotiert. Ich bin mir ziemlich sicher, noch nie in diese Seitenstraßen eingebogen zu sein, ich fahre aber immer diese Hauptstraße in der Mitte entlang (Nord-Süd-Richtung).

Es gab ja mal einen Algorithmus, ich glaube basierend auf Belief Chains, um das zu glätten und eine logischere Straßenfolge zu ermitteln. Ich frage mich, warum der nicht mehr genutzt wird. @florian, vielleicht kannst du das erklären? Hat der nicht richtig funktioniert, oder war er zu langsam? Sollten wir den wieder reaktivieren und vielleicht nochmal über Geschwindigkeit nachdenken?

• Da belief propagation, wenn ich das richtig sehe, als Graph-Problem formuliert werden kann (single source shortest path), könnte uns ein gut optimierte Graphbibliothek dort vielleicht weiterhelfen.
• Wenn wir die PostGIS verwenden für die Query der Straßenabschnitte, können wir darin sehr gut die Kandidaten für jeden Punkt bestimmen, z.B. mit ST_Buffer.
• Vielleicht gibt es ja schon eine Open Source Lösung für dieses Problem. Ist ja nicht unüblich, Tracks auf Routen matchen zu wollen, denke ich. Vielleicht sollten wir uns einfach mal umsehen.

Falls das hier jemensch liest, der:die eh in die Programmierung einsteigen wollte, aber von der Komplexität des Portals mit all seinen Bestandteilen erschlagen ist: Das ist ein super Problem für Leute, die mittel bis viel Programmiererfahrung haben, aber ein sehr eingegrenztes Problem bevorzugen. Viel zu tüfteln, aber der Code ist sehr „lokal“. Antwortet hier oder schreibt mir direkt bei Interesse, das weiter voranzutreiben.

[florian]

Hallo,

der besagte Algorithmus ist seit einer Weile default (osm_projection="filtered" in obs.face.annotate.AnnotateMeasurements.__init__) und sollte eigentlich aktiv sein.

Das Problem, dass du oben siehst, hat vermutlich mehr damit zu tun, dass nicht der richtige (und ein paar falsche), sondern nur falsche Kandidaten für Straßen aus der Karte bestimmt werden, so dass der Algorithmus keine (gute) Wahl hat. Das könnte zum Beispiel daran liegen, dass die Fahrtrichtung in dem Augenblick völlig falsch war und deswegen die Hauptstraße von vorne herein verworfen wurde, oder dass die GPS-Position sehr falsch war.

Wenn du bereit bist, mir die im Verdacht stehenden Tracks zukommen zu lassen, könnte ich es es mir weiter anschauen.

Zum Algorithmus: Es ist wie als graphisches Modell formuliert, genauer als Markov Chain. Jeder GPS Messpunkt ist ein Knoten in dem Graph, die zwei Nachbarn sind der vorherige und darauf folgende Messpunkt. Pro Knoten gibt es bis zu drei Kandidaten, aus denen der beste ausgewählt werden soll, in Abhängigkeit der Nachbarn. Das lässt sich zum Glück - weil es eine Kette ist - effizient und optimal lösen: glaube es ist linear in der Anzahl Knoten (Länge des Tracks) und quadratisch in der Anzahl Labels (hier: 3). Daher vermute ich, dass da bezüglich Laufzeit nicht viel zu holen ist.

Die Bestimmung der Kandidaten (alle Straßen in der Nähe eines Messpunktes mit bestimmten Eigenschaften) ist meiner Einschätzung nach der Flaschenhals. Die Datenstruktur ließe sich sicher verbessern. Wenn ST_Buffer das schneller kann, dann ist das natürlich auch ein Weg.

Ansonsten gibt es Graphhopper, der „snap-to-road“ unterstützt.

[opatut]

Aha, er sollte also aktiv sein! Gut, dann investigiere ich das auch mal weiter. Tracks suche ich dir bei Gelegenheit raus, ist etwas umständlich gerade.

api/scripts/obs/face/annotate/BeliefPropagationChain.py sah mir halt sehr unoptimiert aus. Also da sind eine Menge schleifen und so drin, und np.max oder np.sum im Schleifenkörper. Das schreit dann schnell nach O(n^2), aber ich bin mir nicht sicher, der Algorithmus könnte da schlauer sein.

Trotzdem dachte ich an eine C-Bibliothek mit Python bindings, das ist gerne mal um einige Faktoren schneller, auch wenn es die gleiche Logik macht und gleiche Komplexitätsklasse hat.

Aber wenn das Ding gerade an ist und nur nicht featuremäßig gut genug, dann können wir ja einfach die Technologie lassen und an den Parametern herumspielen. Ich dachte nur es sei vielleicht aus weil zu langsam, aber zu langsam ist es gerade nicht. Vielleicht erhöhe ich mal label und gewichte dafür die Straßenzüge anders statt hart nach Fahrtrichtung zu filtern oder so. Mal schauen, hat gerade bei mir keine Prio

[simse]

moin,
finde das Thema ziemlich spannend und in unserem Portal bzw. meinen tracks (siehe Bild, OpenBikeSensor Portal ) fällt mir das auch immer mal wieder auf, dass es den Track auf Nebenstraßen/Zufahrten legt.

Gibt es den im (Frontend-)Config die Möglichkeit die Parameter dafür anzupassen um beispielsweise Nebenstraßen/Zufahrten super-klein zu gewichten? Oder muss man dafür richtig tief rein?

[opatut]

Gibt es den im (Frontend-)Config die Möglichkeit die Parameter dafür anzupassen um beispielsweise Nebenstraßen/Zufahrten super-klein zu gewichten? Oder muss man dafür richtig tief rein?

Nein die Option gibt es zur Zeit nicht, und das wäre vermutlich auch tief eingebaut. Ich glaueb auch nicht, dass das ein sinnvoller Ansatz wäre. Viele Radfahrende nehmen ja gern Nebenstraßen, wenn diese z. B. parallel zu einer Hauptstraße führen und weniger befahren sind. Ich denke, der Belief-Chain Ansatz ist zielführender. Ich muss den mal wieder fit machen…

[markus]

Hi zusammen,
ich habe die ersten Testfahrten hinter mir. Beim Prüfen der Tracks ist mir eine ziemliche Abweichung von GPS Route und den Straßen aufgefallen.

Der Algorithmus findet hier ganz gut die Strecke, allerdings habe ich auch schon die Rückmeldug bekommen, so wie oben, dass ganz andere Strecken gefahren wurden.
Woran liegt diese relative Ungenauigkeit des GPS? Ich bin da schon 4 km unterwegs gewesen. Kann man hier etwas optimieren?

Für Überholungen passt die Position erfreulicherweise ziemlich gut, obwohl das GPS sich ganz woander wähnt.

Ist das Zufall, oder werden für Überholungen nochmal dedizierte GPS Daten abgerufen?

Danke und Grüße
Markus

[gluap]

Hallo Markus, für die Überholungen werden keine dedizierten GPS daten abgerufen - Die Überholvorgänge werden beim Einlesen ins Portal der nächsten anhand von Fahrtrichtung- und Befahrungsregeln passenden befahrbaren Straße aus der Openstreetmap zugeordnet, deshalb haben sie auf die nächste Straße „gesnapped“.

Die Ungenauigkeit des GPS Tracks lässt sich nicht groß verbessern. Das GPS kommt aus einem Preissegment in dem ein paar Meter Positionsrauschen nicht ungewöhnlich sind - bei klarem Himmel mal weniger, in Häuserschluchten oder im Wald bei Starkregen mal mehr. Wenn es sehr arg ist kann ein Austausch der Antenne oder des Moduls Besserung bringen, aber deine Screenshots sehen für mich normal aus. Tatsächlich sind viele Navi-Geräte „von der Stange“ auch nicht mit besseren GPS Empfängern unterwegs - Es sieht aber so aus als wäre man direkt auf der Straße, weil sie die Fahrzeugposition auf die nächste Straße „snappen“. Klar - Im Hochpreissegment wirds dort auch genauer. Aber auch bei meinem Wandergarmin kann ich in einer Allee unter dichtem Blätterdach durchaus mal auf der Karte „im nächsten Haus“ stehen.

Für mehr Geld könnte man das auch beim OpenBikeSensor genauer bekommen - Aber die große Mehrheit der Abstandsmessungen wird bislang der richtigen Straße zugeordnet, messtechnisch macht es also keinen großen Unterschied.

[matthias-ms]

0

Bin 3x in Münster gefahren und die Daten sind etwas widersprüchlich: es gibt Lücken und auf der Umgehungsstraße darf/will man ja auch nicht fahren. Lässt sich das händisch fix korrigieren oder besser so einrichten, das gewisse Strassen einfach Tabu sind?

[gluap]

Wenn eine Straße für den Radverkehr nicht zugelassen ist, sollten im Portal keine events darauf gemappt werden. Um auszuwerten, ob sie für den Radverkehr zugelassen ist verlassen wir uns auf die OpenStreetMap - Die entsprechenden Segmente sollten entsprechende tags besitzen, z.B. bicycle=no. Wenn man das in der OpenStreetMap ergänzt hat, kann man sobald geofabrik die Daten gedumpt hat nach dem nächsten download und import der OpenStreetMap Daten ins Portal dann die Auswertung neu anstoßen. (ich mache normal nach dem Import der Openstreetmapdaten: overtaking events löschen, dann neuauswertung der Tracks auslösen):
(vorher mache ich einen datenbankdump)

DELETE FROM overtaking_event;
DELETE FROM road_usage;
UPDATE track SET processing_status = 'queued';

Danach sollten die Events unter Beachtung der aktuellen Openstreetmap informationen neu ausgewertet sein - Kann aber ein paar Stunden dauern bis alles neu gerechnet ist.

[matthias-ms]

Deine Antworten klingen immer so logisch und stimmen wohl auch… Dankeschön

Auf dieser Bundesstraße konnte man in dem Bereich bis eben Rad fahren: Habe Fußgänger und Pferde auch mit rausgenommen

[opatut]

Bitte beachtet bei solchen Änderungen in OSM auf jeden Fall immer die üblichen OSM-Vorgaben, in diesem Fall insbesondere die Standard-Zugangsbeschränkungen (siehe Bild) nach Land und Straßentyp (highway). Da es sich hier um highway=trunk handelt, dürfen standardmäßig Fahrräder dort fahren, ein explizites Verbieten mit bicycle=no ist also in Ordnung, sofern dies den lokalen Gegebenheiten entspricht.

Das wäre an der Stelle natürlich zu klären, und optimalerweise vor Ort zu überprüfen oder aus Ortskenntnis abzuleiten, ein entsprechendes Verkehrszeichen, z. B. Zeichen 254 oder Zeichen 331.1 müsste dort meines Erachtens angebracht sein. Ansonsten wüsste ich nicht, was ein Befahren mit Fahrrädern dort ausschließen sollte, kenne den Ort aber natürlich nicht und bin auch kein Verkehrsanwalt

Denkt nur einfach immer dran, das Thema ist ein bisschen komplex in OSM

---

[gluap]

@matthias-ms (Bezugnehmend auf deine Commit message in der OSM, dass Bundesstraßen standardmäßig nicht für Radfahrer [zugelassen] seien) Bundesstraßen gibt es in den verschiedensten Breiten - Deshalb ist „Fahrrad verboten“ nicht Standard dafür - Die StVO erlaubt ohne Zusatzschilder, dort Rad zu fahren. (wie @opatut schon geschrieben hat). Die B3 zwischen Frankfurt und Heidelberg ist z.B. auf weiten Strecken - auch ohne Radweg - für Radfahrer zugelassen und auch streckenweise gar nicht unangenehm zu fahren. Die OpenStreetMapregel setzt da einfach die Straßenverkehrsordung um. Da die B54 dort wo du nachgetragen hast stark autobahnmäßig aussieht vermute ich aber mal dass es da ein „nur Autos“ oder „fahrrad verboten“ Zeichen gibt. Es gibt aber durchaus auch vierspurige Straßen mit Leitplanken die für Radverkehr zugelassen sind, da sollten wir natürlich keine (falschen) bicycle=no tags hinzufügen (z.B. auf der B3 zwischen Darmstadt und Pfungstadt, die dort auch als Umgehungsstraße ausgestaltet ist).

[matthias-ms]

ich kapiere es nicht. am besten lösche ich alles und spiele nix mehr ein: ich bin jetzt 4 touren gefahren, die Daten sehen in der Vorschau ganz gut aus und nach der Freigabe fehlen Teile (die Strecke am Kanal fehlt) oder es wurde besagte B51 befahren, ohne das ich dort war .

[matthias-ms]

habe nun alle routen gelöscht und das letzte Bild erscheint weiterhin. mal schauen ob es morgen auch noch so ist. (hätte jetzt erwartet, das alles weg ist.)

[gluap]

Auf welchem Portal bist du denn unterwegs? (damit ich mal gucken kann, entweder hat dein Browser die Kachel im Cache oder es könnte eibe alte portalversion sein)

[opatut]

Dein Browser merkt sich die Ansicht auf der Hauptkarte für 7 Tage. Wenn du das erneuern möchtest, kannst du deinen Browsercache leeren, oder einen anderen Browser verwenden. Das ist ein Mechanismus, um Rechenlast auf dem Server zu sparen.

Du kannst auch (in Firefox oder Chrome) über die Entwickler:innen-Werkzeuge den Cache deaktivieren, im „Netzwerk“ Tab gibt es dafür oben ein Häkchen.

Firefox: Burger-Menü > More Tools > Web Developer Tools > Network (Tab) > „Disable Cache“

Chrome: 3-Punkte-Menü > More tools > Developer Tools > Network (Tab) > „Disable Cache“

Solange diese Ansicht dann offen bleibt ist dein Cache deaktiviert und du kannst mit F5 die Karte neu laden und bekommst neue Daten.

Übrigens hilft es nicht so viel, wenn du deinen Track neu hochlädsts, die OpenStreetMap Daten müssen erst von der:dem Maintainer:in des Portals neu heruntergeladen und importiert werden. Bis dahin wird die B51 weiter als fahrradbefahrbar angesehen.

[gluap]

Habs gefunden.

Einer deiner tracks ist wohl noch da:

Und auf der Karte gibt es entlang deiner Fahrt bei der Umgehungsstraße einfach keine Fahrradbefahrbare (siehe edit) Straße (graue Linien), deshalb landest du mit deinem Track immer auf der Umgehungsstraße.

Sieht aus als gäbe es da noch ein paar Fehler in der openstreetmap.

Darüber hinaus: wie @opatut schreibt und ich auch geschrieben hatte kommt die Änderung erst beim nächsten Reimport der Karte auf dem Server an.

Edit: see next post

[matthias-ms]

das habe ich in der Zwischenzeit alles gemacht: browserwechsel, cache und cookies leeren, nun ist es hoffentlich weg. besagten Datensatz 5504 vorher gedownloaded (heißt jetzt anders, warum?) und wieder eingespielt und veröffentlicht. ergebnis ist identisch. g1cxb0pp.csv (962,8 KB)

https://obs.radentscheid-essen.de/tracks/u8pj2dhm

Keine Ahnung woran es liegen könnte. an der Bundesstrasse sicher nicht.

https://obs.radentscheid-essen.de/map#14.04/51.95373037980282/7.6501745173625695

das kam jetzt zeitgleich. ich muß immer über die Fußgängerbrücke ÜBER die B51 - ob es daran liegt?

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