Mindestanforderung Inhalte der Datendatei?

Design & Entwicklung Portal & Datenverarbeitung
#1

Moin zusammen,
Matthias hier, relativ neu dabei, und ich fahre seit zwei Wochen mit einem ADFC-Sensor im nördlichen Berliner Umland herum.

Leider sind von meinen wenigen bisher registrierten Überholungen knapp die Hälfte auf parallele Seitenstraßen geschnappt, weil das GPS nicht genau genug ist. Zur Korrektur bastele ich gerade ein Python-Skript, das

  • den Track aus dem OBS einliest
  • einen parallel aufgezeichneten oder anderweitig erstellten GPX-Track einliest
  • (Nur!) die Überholungsereignisse auf den nächstliegenden Punkt aus dem GPX verschiebt
  • einen geeigneten Datensatz speichert

Für den letzten Punkt frage ich mich, was der „geeignete Datensatz“ ist.

Mangels Zeitstempel kann ich nicht jeden Punkt aus dem OBS aufs GPX mappen, wenn ich das nicht direkt mit aufgezeichnet sondern im Nachhinein konstruiert habe. Damit kann ich dann auch die übrigen Sensormesswerte, Geschwindigkeiten, Satellitenzahlen usw. nicht zuverlässig auf das GPX legen, weil es ohne Zeitstempel bei stark streuendem GPS entweder rechnerisch oder algorithmisch unglaublich kostspielig wäre, den gesamten Track halbwegs zu mappen.

Die erhoffte Lösung? Abspecken!

Unmittelbar notwendig für die Auswertung im Portal sollten ja eigentlich nur die Datenspalten

Zeit, Lat, Lon, Links, Rechts, Tastendruck

sein, und selbst die Zeit muss nicht exakt sein.

Jetzt die Frage(n):

Was ist die Mindestanforderung an die Auswahl der Datenspalten in der hochgeladenen Datei, damit das Portal die Datei auswertet?

Falls alle Spalten vorhanden sein müssen, was ist die Mindestanforderung an sinnvoll gefüllten Spalten, bzw. welche Spalten kann ich leer lassen oder Dummys hineinschreiben, so dass die Auswertung trotzdem mit sinnvollen Daten gefüttert wird?

Viele Grüße,
Matthias

#2

Hallo Matthias,

ohne das konkrent nachgeschaut zu haben, denke ich dass das auch funktionieren sollte, wenn du nur einen Teil der Zeilen und Teil der Spalten behältst. Allerdings wäre es gut, wenn du dann zumindest die Formatspezifikation befolgst und insbesondere OBSDataFormat=2 angibst, denn in den vorigen Versionen (ohne Metadatenzeile) wurde das Dateiformat anhand der vorhandenen Spalten erkannt und die Werte entsprechend unterschiedlich interpretiert.

Der Importer versucht auf jeden Fall für Format 2 alle Spalten zu lesen. Wie er mit fehlenden Spalten umgeht kann ich dir nicht genau sagen, damit hab ich nie experimentiert und das hab ich auch nicht programmiert. Einfach mal versuchen?

Allerdings wäre es denke ich schön wenn du für alle Punkte/Zeilen im CSV dein Snap-to-actual-track machen könntest. Das Portal wertet mehr aus als nur die Überholmanöver, wir versuchen auch rauszufinden auf welchen Straßenabschnitten (viel/wenig) gefahren wird, unabhängig von den Überholevents, um Aussagen wie „hier wird [oft-selten] [schlecht-gut] überholt“ tätigen zu können.

Prinzipiell könnten wir das mal weiter spinnen und evtl direkt ein combined-track-and-measurements matching in das Portal einbauen. Ich habe da eh mal angefangen den Import neu zu schreiben, auch für OBS Lite (weiß gerade nicht was daraus geworden ist, muss ich mich erstmal wieder reinlesen). Mit der neuen Architektur wird das leichter sein, mehrere Quellen zusammenzuführen, weil das OBS-Lite Format darauf ausgelegt ist. Dann fehlt nur die Unterstützung im Frontend und der API für mehrere Dateien pro Track, aber das lässt sich sicher auch machen.

Berichte gern mal wie das kombinieren und hochladen für dich funktioniert, wenn du es ausprobiert hast. Schau auch gern wie sich das auf die Statistik der Straßenbenutzung auswirkt.

LG Paul

1 „Gefällt mir“
#3

Hallo Paul,
Danke Dir! Ich hänge ein Bild an, das verdeutlicht, warum ich nicht ohne weiteres für alle Zeilen ein Snap-to-actual-track umsetzen mag.

grafik
grafik370×548 61.2 KB

Ich bin im Bild entlang der grünen Linie von Nord nach Süd gefahren, der OBS hat dabei die blauen Punkte aufgezeichnet. Im Bereich der Abbiegungen liegen die aufgezeichneten Punkte so weit vom echten Track entfernt bzw. einfach quer dazu, so dass ich an mindestens zwei Stellen einzelne Datenpunkte habe, die vorwärts auf das nächste oder rückwärts auf das vorherige Segment hüpfen würden anstatt auf das, was ich eigentlich gerade brauche. Damit entstehen dann physikalisch ziemlich merkwürdige Datensätze.

Will man es richtig machen, dann müsste man eine Bewegung des Sensors simulieren (inkl. Kurs und Geschwindigkeit und ggf. GPS-Unsicherheit) und dann die Punkte nach größter Wahrscheinlichkeit an die richtige Stelle verschieben. Das wäre dann keine rein geometrische Operation mehr, und das ist mir für zwischen Tür und Angel gerade wirklich zu kompliziert.

Wenn es allerdings im Portal lediglich darum geht, die Straßenbenutzung auszurechnen und der Auswertemechanismus zuverlässig ignoriert, dass ich dann möglicherweise wild zwischen den gleichen Straßen mehrfach hin- und herspringe und fröhliche 180°-Wenden reiße, dann kann ich das gern machen.

Herzliche Grüße,
Matthias

#4

Hihi, lieber nicht. Der Algorithmus zählt Straßenbenutzung auch mehrfach, wenn du zwicshendurch eine andere Straße benutzt hattest :smiley:

Ich kenne genau dies Art von Track. Der neue Algorithmus macht ja genau das, ein bisschen mehr als nur eine einfache 1:1 Modifikation der Koordinaten. Vielleicht schafft der es schon halbwegs, deine grüne Linie zu matchen.

Mangels Zeitstempel kann ich nicht jeden Punkt aus dem OBS aufs GPX mappen

Das ist natürlich ärgerlich, dass dir der Zeitstempel fehlt. Die GPS-Zeit sollte ja identisch sein bei beiden Geräten, unabhängig davon wie gut die Position ist. Ich bin übrigens erstaunt wie akkurat dein Referenz-GPS ist im Vergleich zum Neo-6M im OBS.

LG Paul

#5

Ach so, das hätte ich deutlicher schreiben sollen. Meine Referenz ist ein im Nachhinein von Hand gerouteter Streckenverlauf. Ich war ja dabei und konnte mich erinnern :wink: Deswegen hat der auch weder Zeitstempel noch Geschwindigkeitsprofil, sonst könnte ich ja was sinnvolles damit machen. Aber so habe ich leider wirklich nur die Geometrie als Eingangsinformation.

Ich experimentiere übrigens parallel mit SimRA, weil - wenn ich ohnehin im Nachhinein Aufwand betreiben muss, um die Daten zu korrigieren, kann ich eventuell auch aus dem SimRA-Export eine OBS-Trackdatei basteln. SimRA spielt die Ereignisse des OBS an einen Track des Handystandorts, und der ist deutlich besser (weil mit Inertialdaten gestützt usw.).

Praktisch wäre dann natürlich ein Import für SimRA-Dateien im Portal…