Zuordnungen von Überholungen entgegen der "oneway"-Richtung (Vergleich Portal und obs-face Script)

Hilfe / Support Portal & Datenverarbeitung
#1

Hallo,
ich versuche obs-Daten für Augsburg zu analysieren, ich habe einerseits die Daten aus dem https://obs.adfc-bw.de/ Portal, andererseits Daten/csv-Dateien aus drei obs-Geräten, die in den letzten Jahren in Augsburg im Einsatz waren.
Dabei sind ein paar Fragen aufgekommen, bei denen ich nicht weiterkomme:
Im obs.adfc-bw Portal gibt es beim Export die Möglichkeit, die Option „Events auf die zugeordneten Straßensegmente ‚snappen‘.“ zu wählen. So weit ich sehen kann gibt es aber keinen Unterschied in den heruntergeladenen Daten, wenn die Option gewählt/nicht gewählt ist?

Eigentlich dürften Überholpunkte mit "direction =-1 nicht an OSM Wegsegmenten vorkommen, die mit „oneway“=‚yes‘ getagged sind, weil es sich hier entweder um Überholungen durch Autos handeln müsste, die falsch in der Einbahnstraße gefahren sind, oder um Zuordnungen zum falschen Wegsegment, wenn Straßen in der OSM durch zwei (gerichtete) Segmente dargestellt werden, oder?

Wenn ich mir die Daten aus dem obs.adfc-bw Portal anschaue, sind an einigen Wegsegmenten über die Hälfte der Messpunkte scheinbar falsch zugeordnet (mit „OSM_oneway“=‚yes‘ AND „OSM_way_orientation“=-1).
Weil die Daten aus dem Portal ja einer nicht ganz aktuellen OSM zugeordnet sind, und ich diesen Forums-Beitrag Obs-face -ACV und "Position der Messung (korrigiert):" so verstehe, dass es sinnvoller wäre, mit dem Portal anstatt mit dem Script zu arbeiten, habe ich (ca. nach dieser Anleitung nur nicht auf MacOS Schritt-für-Schritt-Anleitung: OpenBikeSensor-Portal lokal auf macOS installieren) mit einem lokalen Portal mit aktueller OSM verarbeiten und visualisieren lassen.
Dabei komme ich auf 762 Punkte von knapp 8000 Überholpunkten, die mir fehlerhaft zugeordnet erscheinen, weil „OSM_oneway“=‚yes‘ AND „OSM_way_orientation“=-1. Sie befinden sich ganz überwiegend an Straßen, die in der OSM als zwei parallele Linien digitalisiert sind.

(ich glaube ein ähnlichs Problem wurde hier schon diskutiert Richtungs-Zuordnung bei baulicher Trennung)

Wenn ich die Daten, die ich aus den drei obs habe, mit dem Script GitHub - openbikesensor/OpenBikeSensor-Scripts verarbeite, bekomme ich bei nur vier von gut 8100 Überholpunkten eine Zuordnung entgegen der Fahrtrichtung („OSM_oneway“=‚yes‘ AND „OSM_way_orientation“=-1).

Warum ist das beim Portal so viel häufiger als beim Script?
(Und warum kann das Portal ca. 100 Überholpunkte weniger zuordnen als das Script?)

Wäre sehr dankbar, wenn mir hier wer weiterhelfen kann
(und gerne auch Bescheid geben, falls dies der falsche Ort für diese Fragen war oder die Fragen nicht verständlich sind).

Danke und viele Grüße

#2

Das passt schon, die Frage hier zu stellen.

Unterschiede zwischen Scripts und Portal

Das Script aus „OpenBikeSensor Scripts“ ist ziemlich alt. Damals haben wir für jedes Straßensegment Overpass (eine API der Openstreetmap) abgefragt (und teilweise gecached). Das ist aber auf der Skala eines Portals irgendwann nicht mehr die feine englische Art, weil Overpass nicht als „backendservice“ für webseiten gedacht ist. Deshalb wurde der Snapping algorithmus mehrfach neu geschrieben um eine lokale postgres datenbank zu nutzen und zuletzt komplett renoviert.

Das ist also komplett unterschiedlicher Code für das Snapping zwischen dem Portal und dem Scripts repository. Das lässt sich auch nicht einfach auf das Scripts repository übertragen, weil der Algorithmus im Portal die Postgis Datenbank mit den Straßen braucht, die natürlich nicht jeder der das Script verwenden will einfach installieren kann.

Der Unterschied ist: Während früher nur Ort und Bewegungsrichtung relevant waren, versucht der neue Algorithmus, eine logische Straßenabfolge zu rekonstruieren, die so auch gefahren werden kann. Daher sind Unterschiede zwischen den beiden Alogorithmen erwartbar. Der neuere Algorithmus ordnet ein paar weniger Events zu, weil bei sehr unwahrscheinlichen Fahrtwegen (bei denen der Fahrer sich z.B. über viele Meter zwischen Wegen teleportieren müsste) öfter auf Eventzuordnungen verzichtet wird, weil man keine sicheren Aussagen machen kann. Den alte Algorithmus hat das weniger gestört.

Snapping entgegen Einbahnstraßen

Was natürlich trotzdem nicht passieren sollte, ist die Zurodnung von Events entgegen Einbahnstraßen. Um das Problem genauer nachzuvollziehen, habe ich in den Datenbanken von zwei Portalen gesucht, auf denen ich Admin bin.

Im ADFC Hessen Portal kann ich unter ca. 90.000 Events etwa 5000 events finden, die „entegegen Einbahnstraßen“ gemapped wurden.

Besonders häufig z.B. hier in der Hamburger Allee in Frankfurt, oder in der Marburger Allee in Gießen - genau die Situation, die du beschreibst: Straße mit baulicher Trennung, separat gemapped. Offenbar sind wir hier noch nicht trennscharf genug, was die Einbahnstraßen angeht.

Die Kostenfunktion abhängig von der Fahrtrichtung findet sich hier. Ich schätze, da müssen wir die Gegenrichtung noch teurer machen. Ich schaue mal, ob ich ein Testset gebastelt bekomme mit dem sich das tunen lässt. Wenn du lokal ein jetzt ein Setup hast, kannst du das auch gern daran probieren.

Falls jemand auf seinem Portal reingucken möchte:

So suche ich nach diesen Events:

# Events gegen Einbahnstraße suchen
select count(id) from overtaking_event JOIN road ON (overtaking_event.way_id=road.way_id) WHERE oneway and direction_reversed;
# Eventdetails gegen Einbahnstraße:
select * from overtaking_event JOIN road ON (overtaking_event.way_id=road.way_id) WHERE oneway and direction_reversed;
2 „Gefällt mir“
#3

Wie gesagt, glaube ich dass die Kostenfunktion defekt ist

#4

@jens danke für den Hinweis. Ich dachte das hätten wir damals gefixt. Hatten wir auch. am 28. Februar 2024. Aber stellt sich raus das ist nicht im main branch angekommen.

#5

… Den Fix vom Februar teste ich manuell an den events aus der Marburger Allee in Gießen, bisher sieht es ganz gut aus.

Stand nach ca. 20% der Events neuberechnet sind bisher alle korrekt zugeordnet worden.

1 „Gefällt mir“
#6

… und habe angefangen verschiedene featurebranches in einem Branch zusammenzufassen. Viele der Features waren sogar schon testweise auf einem Portal im Betrieb, weil sie ohne Schemaänderungen testbar waren.

#7

Ich glaube die neue Zuordnung ist ganz gut, ich sehe kaum noch der gegenrichtung zugeordnete Überholvorgänge auf der Karte von obs.adfc-hessen.de.

@nigna bis es ein release gibt, das in Ba-Wü aufgespielt werden kann dauert es aber noch ein bisschen - Es muss ein bisschen aufgeräumt werden, damit auch die anderen Änderungen, die im git auf Veröffentlichung warten mit aufgespielt werden können.

#8

Danke für eure Hilfe!
Bei mir hat es mittlerweile auch geklappt, die Änderung lokal zu anzuwenden und die Zuordnung scheint jetzt richtig zu sein.