@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).
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 .
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.)
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)
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.
Habs gefunden.
Einer deiner tracks ist wohl noch da:
Und auf der Karte gibt es entlang deiner Fahrt bei der Umgehungsstraße einfach
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
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?
@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.
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:
das dicke graue ist die Umgehungsstraße:
@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!
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?
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).
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:
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.
@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.
- Nur auf Autobefahrbaren Wegen?
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.
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?
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