AirlinerView

AirlinerView zeigt Flugbewegungen von adsb.lol oder aus einem inoffiziellen FlightRadar24-Feed als responsive Weboberfläche an. Die Anwendung ergänzt die Rohdaten um Flugzeugnamen, Fluggesellschaften, Flughäfen, Länderflaggen, Logos und Flugzeugbilder.

Zusätzlich steht ein Kommandozeilenprogramm für Abfragen und einen fortlaufenden Watch-Modus zur Verfügung.

Der verwendete FlightRadar24-Endpunkt ist nicht offiziell dokumentiert. Verfügbarkeit, Datenformat und Zugriffsbeschränkungen können sich jederzeit ändern. Die von adsb.lol bezogenen Flugdaten stehen unter der Open Database License (ODbL).

Funktionen

• Suche nach ICAO-Flughafencode, Ort oder Postleitzahl
• automatische Übernahme von Flughafenname und Koordinaten
• Standortbestimmung im Browser
• einstellbarer Radius und Trefferlimit
• Filter für Bodenbewegungen, Hubschrauber, Gleiter und Kleinflugzeuge
• Dummy-Modus für Tests ohne FlightRadar24-Zugriff
• zweistufiges Laden mit früher Trefferanzeige und Fortschrittsstatus
• responsive Darstellung für Desktop und Mobilgeräte
• Hell-/Dunkelmodus mit gespeicherter Auswahl
• Flugkarten mit Foto, Route, Flughäfen, Höhe, Geschwindigkeit und Kurs; Treffer ohne verfügbares Foto werden ausgeblendet
• klickbare Start-/Zielbereiche mit interaktiver Flugplan- und Routenansicht
• lokale Fluggesellschaftslogos und Länderflaggen
• Registrierungsbilder über JetAPI/JetPhotos
• lokale Thumbnail-Dateien und SQLite-Metadaten-Cache
• NEW-Kennzeichnung für erstmals geladene Registrierungsbilder
• Wartungsbereich für Filter, Cache und Logs
• umschaltbare Live-Datenquelle: adsb.lol, FlightRadar24 oder automatischer Rückfall
• Versions- und Git-Statusanzeige in der Fußzeile
• Prüfung auf Updates aus dem konfigurierten Git-Upstream
• klickbares Linux-Update mit anschließendem systemd-Neustart

Voraussetzungen

• Python 3.9 oder neuer
• Git für Versions- und Updateprüfung
• Netzwerkzugriff auf adsb.lol beziehungsweise FlightRadar24, ADSBDB, Flight Plan Database, JetAPI, JetPhotos und OpenStreetMap/Nominatim
• unter Linux optional systemd für die klickbare Updatefunktion

Installation

git clone https://git.hintergasse.de/hubobel/flightradar.git
cd flightradar
python3 -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements.txt

Webanwendung starten

python web_app.py

Danach öffnen:

http://127.0.0.1:8050

Der Server lauscht auf allen Interfaces (0.0.0.0) und Port 8050.

Für die Routenerzeugung wird ein API-Schlüssel der Flight Plan Database benötigt. Er wird in einer lokalen .env im Projektverzeichnis gespeichert:

cd ~/flightradar
nano .env

Inhalt:

FLIGHTPLANDB_API_KEY="dein-api-schluessel"

Dateirechte anschließend einschränken:

chmod 600 ~/flightradar/.env
sudo systemctl restart fr

Die Anwendung liest die Datei beim Start automatisch. Ein export oder ein zusätzlicher Environment=-Eintrag in der systemd-Service-Datei ist nicht erforderlich. .env ist in .gitignore enthalten und darf wegen des API-Schlüssels nicht versioniert werden. Der Schlüssel wird nie an den Browser übertragen.

Screenshots

Helle Ansicht

Dunkle Ansicht

Flugroute und Karte

Hauptseite

Die Hauptseite enthält:

• Standortbestimmung
• Suche nach ICAO, Ort oder Postleitzahl
• Breiten- und Längengrad
• Radius in Kilometern
• Trefferlimit
• Aktualisieren-Button
• Hell-/Dunkel-Schalter neben dem Wartungszahnrad

Bei einer Aktualisierung erscheint zuerst die Trefferzahl. Anschließend werden Detaildaten und Bilder ergänzt. Bereits gecachte Bilder werden weiterhin lokal verwendet.

Flugroute

Der Start-/Zielbereich einer Flugkachel ist anklickbar, sobald Start, Ziel und Flugzeugtyp vorliegen. Die Detailseite erzeugt in Anlehnung an das Testprojekt Flightdatabase einen Flugplan und zeigt:

• die Route auf einer interaktiven OpenStreetMap-Karte,
• Start- und Zielflughafen,
• Fluggerät und verwendetes Leistungsprofil,
• Distanz, geschätzte reine Flugzeit, Reiseflughöhe und -geschwindigkeit,
• die Route als Text sowie ein Foto des konkreten Fluggeräts mit Link zur Bildquelle.

Erzeugte Routen werden eine Stunde im Arbeitsspeicher zwischengespeichert. Fehlt FLIGHTPLANDB_API_KEY oder ist der Dienst nicht erreichbar, zeigt die Routenseite eine verständliche Fehlermeldung.

Standortbestimmung und HTTPS

Browser erlauben die automatische Standortbestimmung nur in sicheren Kontexten:

• http://localhost und http://127.0.0.1 sind lokale Ausnahmen.
• Beim Zugriff über einen Server ist HTTPS erforderlich.

Für einen entfernten Server sollte AirlinerView daher hinter Caddy, Nginx oder einem anderen HTTPS-Reverse-Proxy betrieben werden.

Wartungsbereich

Der Wartungsbereich ist erreichbar unter:

/maintenance

Abfrageoptionen

Die Optionen werden im Browser gespeichert und bei der nächsten Abfrage verwendet:

• Dummy: eingebaute Testdaten statt Live-Feed
• Boden: Flugzeuge am Boden einbeziehen
• Hubschrauber: erkannte Hubschraubertypen einbeziehen
• Gleiter: erkannte Gleitertypen einbeziehen
• Kleinflugzeuge: erkannte General-Aviation-Typen einbeziehen

Bei adsb.lol werden zusätzlich die ADS-B-Größenkategorien A1 (light) und A2 (small) automatisch als Kleinflugzeuge behandelt. Bleibt bei deaktivierter Option ein weiterer Typ sichtbar, kann er direkt über den „−“-Knopf an der Flugkarte in die lokale Ausschlussliste aufgenommen werden.

Die Typcodelisten liegen in:

aircraft_glider_codes.json
aircraft_helicopter_codes.json
aircraft_small_codes.json

Unbekannte Typcodes bleiben sichtbar, damit nicht versehentlich Verkehrsflugzeuge entfernt werden.

Datenquelle

Die Datenquelle für Flugbewegungen wird serverweit auf der Wartungsseite gewählt:

• Automatisch: verwendet bevorzugt adsb.lol und fällt bei einem Fehler auf FlightRadar24 zurück
• adsb.lol: verwendet ausschließlich die öffentliche adsb.lol-API
• FlightRadar24: verwendet ausschließlich den bisherigen inoffiziellen Feed

Für adsb.lol ist aktuell kein API-Schlüssel erforderlich. Start und Ziel werden zunächst über den adsb.lol-Routendienst ergänzt. Bleibt bei einem nach der Filterung tatsächlich angezeigten Flug eine Route unbekannt, fragt die Anwendung ADSBDB anhand des Callsigns ab. Treffer werden sechs Stunden und unbekannte Callsigns fünf Minuten im Arbeitsspeicher zwischengespeichert. Flugzeuge ohne bekannte Route bleiben sichtbar. Die Einstellung wird lokal in flight_source_settings.json gespeichert.

Registrierungs- und Thumbnail-Cache

Cache-Übersicht:

/maintenance/cache

Metadaten werden gespeichert in:

jetapi_cache.sqlite

Bilddateien werden gespeichert in:

thumbnail_cache/

Eigenschaften:

• Cache-Laufzeit: 90 Tage
• unterstützte Bildformate: JPEG, PNG, WebP und GIF
• maximale Thumbnail-Größe: 10 MB
• vorhandene lokale Bilder werden bevorzugt
• fehlende Bilder fallen auf die externe URL oder ein Musterbild zurück
• Klick auf ein Cache-Vorschaubild öffnet die Originalquelle
• alle Cacheeinträge und Thumbnail-Dateien können nach Sicherheitsabfrage gelöscht werden

jetapi_cache.sqlite und thumbnail_cache/ sind Laufzeitdaten und werden nicht mit Git versioniert.

Logs

Normales Anwendungslog:

logs/flightradar.log

Update-Log:

logs/update.log

Unter /maintenance/logs können Logs angezeigt, heruntergeladen und nach Sicherheitsabfrage gelöscht werden. Das Update-Log besitzt eine separate Ansicht und einen eigenen Download.

Die Anwendungslogs rotieren bei 1 MB; fünf Sicherungen werden aufbewahrt.

Loglevel setzen:

FLIGHTRADAR_LOG_LEVEL=DEBUG python web_app.py

Bilder und Quellen

Die Bildauswahl erfolgt in dieser Reihenfolge:

1. Registrierungsbild aus dem lokalen Thumbnail-Cache
2. neues Registrierungsbild über JetAPI/JetPhotos
3. Airline-/Flugzeugmusterbild
4. allgemeines Flugzeugmusterbild

Neu von JetAPI gefundene Registrierungsbilder erhalten bei der ersten Anzeige ein kleines NEW-Badge. Bereits gecachte Bilder erhalten keine erneute Markierung.

Die Originalquellen bleiben über Bild- und Textlinks erreichbar.

Versionierung und Fußzeile

Die Basisversion steht in:

VERSION

Die Fußzeile zeigt beispielsweise:

Version 1.1.1 · abc12345 · 10.07.2026

Mögliche Ergänzungen:

• lokal geändert: getrackte Dateien weichen vom letzten Commit ab
• Kein Update verfügbar
• UPDATE verfügbar (n Version/Versionen)
• Updateprüfung nicht möglich

Die Updateprüfung nutzt den für den aktuellen Branch konfigurierten Upstream (@{u}) und wird höchstens alle fünf Minuten ausgeführt.

Wichtig:

• Git-Kommandos niemals mit sudo ausführen.
• Repository und Webdienst sollten demselben normalen Benutzer gehören.
• Neue Dateien vor Commit und Deployment mit git status --short kontrollieren.

Klickbares Update unter Linux

Wenn ein Update verfügbar ist, wird der Hinweis in der Fußzeile zum Button. Der Ablauf ist:

1. git pull --ff-only
2. Neustart des systemd-Dienstes
3. Warteseite wartet auf einen tatsächlich geänderten Versions-/Commitstand
4. bei Erfolg Rückkehr zur vorherigen Seite
5. bei Fehler Anzeige UPDATE fehlgeschlagen mit Link zu logs/update.log

Das Hilfsskript muss mit Git versioniert und auf dem Server vorhanden sein:

update_and_restart.py

Der Dienstname ist standardmäßig fr und kann überschrieben werden:

FLIGHTRADAR_SYSTEMD_SERVICE=airlinerview python web_app.py

Erforderlicher sudoers-Eintrag

Bearbeiten mit:

sudo visudo -f /etc/sudoers.d/fr

Beispiel:

hubobel ALL=(root) NOPASSWD: /usr/bin/systemctl restart fr

Die Regel sollte ausschließlich den benötigten Restart-Befehl erlauben.

Beispiel für systemd

[Unit]
Description=AirlinerView
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=hubobel
Group=hubobel
WorkingDirectory=/home/hubobel/flightradar
Environment=FLIGHTRADAR_SYSTEMD_SERVICE=fr
ExecStart=/home/hubobel/flightradar/.venv/bin/python /home/hubobel/flightradar/web_app.py
Restart=on-failure

[Install]
WantedBy=multi-user.target

Danach:

sudo systemctl daemon-reload
sudo systemctl enable --now fr

Für manuelle Updates:

git -C ~/flightradar pull --ff-only
sudo systemctl restart fr

Kein sudo git ... verwenden, da dadurch root-eigene Dateien in .git/objects entstehen können.

Kommandozeilenprogramm

Einfache Abfrage:

python flightradar_query.py

Eigener Mittelpunkt und Radius:

python flightradar_query.py --lat 52.52 --lon 13.405 --radius 15 --limit 10

Beispiele:

# Flugzeuge am Boden einbeziehen
python flightradar_query.py --ground

# Gleiter ausschließen
python flightradar_query.py --no-gliders

# Hubschrauber ausschließen
python flightradar_query.py --no-helicopters

# Kleinflugzeuge ausschließen
python flightradar_query.py --no-small-aircraft

# Testdaten verwenden
python flightradar_query.py --dummy

# ausschließlich adsb.lol verwenden
python flightradar_query.py --source adsb_lol

# fortlaufender Watch-Modus
python flightradar_query.py --watch

# URL und wichtige Header ausgeben
python flightradar_query.py --debug

Im Watch-Modus:

• werden gefundene Flüge nacheinander im Abstand von 10 Sekunden ausgegeben,
• wird nach dem letzten Flug neu abgefragt,
• wird bei null Treffern 30 Sekunden gewartet,
• wird nach Fehlern 60 Sekunden gewartet.

Daten- und Konfigurationsdateien

aircraft_full.json                 Flugzeugtypnamen
airlines_full.json                 Fluggesellschaften
airports_full.json                 Flughäfen und ICAO/IATA-Zuordnung
aircraft_images.json               allgemeine Musterbilder
airline_aircraft_images.json       Airline-/Musterbilder
airline_aircraft_profiles.json     typische Flugzeugmuster je Airline
airline_logos.json                 Logo-Metadaten und Quellen
_banners/                          lokale Airline-Banner
_logos/                            lokale Airline-Logos
appearance_settings.json           gewählte Airline-Darstellung
flight_source_settings.json        gewählte Quelle der Flugbewegungen
country_flags/                     lokale Länderflaggen
aircraft_glider_codes.json         Gleitertypen
aircraft_helicopter_codes.json     Hubschraubertypen
aircraft_small_codes.json          Kleinflugzeugtypen
aircraft_profiles.json             Leistungsprofile für die Routenerzeugung

Alle Projektdateien werden relativ zum Speicherort von web_app.py aufgelöst. Dadurch sind keine benutzerspezifischen absoluten Pfade erforderlich; dieselbe Struktur funktioniert unter Linux, macOS und Windows.

HTTP-Endpunkte

Wichtige Seiten und APIs:

/                                  Hauptseite
/maintenance                       Wartung
/maintenance/cache                 Cacheübersicht
/maintenance/logs                  Anwendungslog
/maintenance/logs/update           Update-Log
/route                             Routendetailseite
/api/flights                       Flugabfrage
/api/data-source                   Datenquelle lesen und ändern
/api/route                         serverseitige Flugplanerzeugung
/api/geocode                       ICAO-/Ortssuche
/api/reverse-geocode               Rückwärtssuche für Koordinaten
/api/version                       Versions- und Updatestatus

Die Endpunkte sind für den lokalen beziehungsweise vertrauenswürdigen Betrieb gedacht. Insbesondere /app/update und die kosten- beziehungsweise limitrelevante Routenerzeugung unter /api/route sollten bei öffentlich erreichbaren Installationen durch Authentifizierung oder den Reverse-Proxy geschützt werden.

Git-Check vor dem Deployment

git diff --check
git status --short

Neue Dateien müssen ausdrücklich hinzugefügt werden:

git add <datei>

Anschließend:

git commit -m "Beschreibung der Änderung"
git push