ADS-B in Zeitreihendatenbanken

07.07.2018

Weitere Gedanken zu ADS-B Daten und deren Nutzung

Überlegungen

Nachdem ich - wie in einem früheren Artikel bereits beschrieben - wieder einmal einen auf SDR basierenden ADS-B Lauscher in Betrieb nahm, machte ich mir Gedanken über die Speicherung und Analyse der anfallenden Daten.

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

Menschen, die Influx kennen, werden sich jetzt fragen, warum das alles so kompliziert ist - ich könnte ja einfach die Webschnittstelle von Influx benutzen um direkt neue Datensätze einzufügen - warum also der Weg über die komplizierte Zwischen-Datei?

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

An diesem Punkt angekommen stellte ich fest, dass ich ja diverse interessante Informationen - schon allein nur aus den ADS-B Daten - gewinnen könnte: Eine davon wäre, herauszufinden, wann genau bestimmte Flüge stattfinden. Dazu müsste ich aber die zusammenhängenden Datenpunkte herausfinden können. Intuitiv ist das Kriterium dafür schnell gefunden:

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:

Alle Artikel rss Wochenübersicht Monatsübersicht Github Repositories Gitlab Repositories Mastodon Über mich home xmpp


Vor 5 Jahren hier im Blog

  • Mandelbrot-Sets mittels Shadern berechnen

    17.05.2019

    Nachdem ich in den letzten verregneten Tagen auf Youtube in den Videos von Numberphile versunken bin, hat mich eines davon angestachelt, mich selbst mit dem Mandelbrotset zu beschäftigen. Als ich dann noch Code fand, der behauptete, das auf einer Graphikkarte mittels Shadern berechnen zu können, war es um mich geschehen...

    Weiterlesen...

Neueste Artikel

  • Erste Vor-Version eines Gis-Plugin für die sQLshell

    Wie bereits in einem früheren Artikel erwähnt plane ich, demnächst ein Plugin für die sQLshell anzubieten, das eine Visualisierung von Daten mit räumlichem Bezug im Stil eines Geoinformationssystems erlaubt.

    Weiterlesen...
  • bad-certificates Version 2.1.0

    Das bereits vorgestellte Projekt zur automatisierten Erzeugung von Zertifikaten mit allen möglichen Fehlern hat eine Erweiterung erfahren und verfügt über ein Partnerprojekt - beide sind nunmehr in der Version 2.1.0 freigegeben

    Weiterlesen...
  • SQLite als Geodatenbank

    Wie bereits in einem früheren Artikel beschrieben treibe ich derzeit Anstrengungen voran, die sQLshell attraktiver für Nutzer zu machen, die mit Geodatenbanken arbeiten.

    Weiterlesen...

Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.

Wer daran teilhaben und eventuell sogar davon profitieren möchte, muß damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.

Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...

PS: Meine öffentlichen GitHub-Repositories findet man hier - meine öffentlichen GitLab-Repositories finden sich dagegen hier.