Weitere Gedanken zu ADS-B Daten und deren Nutzung

Überlegungen

Die Daten könnten natürlich zunächst erst einmal in einer Datei gespeichert werden. Dazu ist kein großartiger Aufwand nötig - ein paar Zeilen Python reichen aus. Das geht - etwas unkonventionell - sogar noch einfacher:

wget -O - -q http://myreceiver:30003 28 > log.txt .csv

Aber diese Datei müsste später ja trotzdem wieder eingelesen und in geeigneter Form analysiert werden - da gibts doch bestimmt etwas Fertiges?

An diesem Punkt angelangt war die Entscheidung leicht, sich doch endlich einmal mit Zeitreihendatenbanken zu befassen. Also las ich mir zunächst Reviews einiger üblicher Verdächtiger durch und stieg bei einigen tiefer in die Dokumentation ein. Die Zeitreihendatenbank Influx gefiel mir an diesem Punkt angekommen am besten - daher machte ich mir Gedanken über den nächsten Schritt in der Pipeline: Bisher hatte ich ja schon einige hinter mich gebracht:

Empfang

DVB-T-Receiver (SDR-fähig)

Dekodierung

dump1090

Speichern in Dateien in SBS1 (BaseStation)

py1090

Speichern in Zeitreihendatenbank

Influx

Wie aber aus dem SBS1-Format eines machen, das ich in die Influx-DB importieren kann? Denn die kann natürlich mit SBS1-Dateien nichts anfangen... Glücklicherweise existiert das Line Protocol, welches einen standardisierten Weg anbietet, Importdateien zu schreiben, mit denen Influx etwas anfangen kann.

Daher muss ich jetzt nur noch einen Konverter von SBS1 ins Line-Protocol schreiben. Dann steht einem Bulk-Import nichts mehr im Wege.

Abbildung auf reale Infrastruktur

Nun - mein Raspi ist nicht mit zusätzlichem Massenspeicher ausgerüstet. Daher verbietet sich die Installation einer jeglichen Datenbank auf diesem System von selbst. Und ich habe vor, den Raspi an dem einen oder anderen Tag mitzuführen - dann werde ich nicht über Netzwerkkonnektivität verfügen und also wird der Raspi auch außerstande sein, Verbindung zu einer remote Influx-Instanz aufzunehmen. Daher also die Entscheidung, die SBS1-Daten zunächst zu speichern und in einem zweiten Schritt zu konvertieren und in Influx zu importieren.

Es kommt noch ein weiterer Grund hinzu: die Daten, die ich in Influx importiere, sind nicht notwendigerweise die die ADS-B liefert: Beispielsweise können Datenpunkte dabei sein, in denen noch keine Position vermerkt ist. Je nach Anwendungsfall könnte ich entscheiden, dass mich solche Datenpunkte nicht interessieren - vielleicht ergibt sich auch ein Anwendungsfall, in dem mich nur solche interessieren. Der Import in die Datenbank würde sich natürlich drastisch unterscheiden. Man sieht wieder einmal: Rohdaten aufzubewahren lohnt sich!

Außerdem kann es sein, dass ich mich dafür entscheide, die Zeitreihendatenbank mit weiteren Informationen anzureichern, die ich aus öffentlich zugänglichen Datenbeständen gewinnen kann - wie etwa Informationen zu Betreiber, Hersteller und Modell des Flugzeuges. Diese Informationen kann ich aber erst mit Netzwerkzugang gewinnen.

Datenbank-Abfrage Denkaufgabe

Man sortiere die Datenpunkte entsprechend des Erfassungszeitpunktes und suche nach großen Pausen in dieser Zeitreihe. Das ließe sich graphisch sofort und sehr schnell machen: die Pausen müssten sofort ins Auge springen.

Dieses Problem in einer Datenbankabfragesprache zu formulieren stellte mich allerdings vor Herausforderungen - sowohl in SQL als auch in Zeitreihendatenbanken. Die momentan am besten scheinende Umgehung dieses Problems ist, darauf bei der Erfassung einzugehen: Jeder erfasste Datenpunkt wird aufbewahrt, bis der nächste erfasst wird. Dann wird in diesen der Erfassungszeitpunkt des letzten eingetragen. Damit wird das Problem in der Datenbank trivial.

Ich suche nichtsdestotrotz noch nach einerLösung für unabhängig voneinander erfasste Datenpunkte.

Zum Abschluss noch einige Links:

Links

Kommentar hinzufügen (via ) Kommentare ansehen (via )

Kommentar hinzufügen (via ) Kommentare ansehen (via )