AeroACARS v0.16.24

v0.16.24 — Präzise Landebahn-Erkennung auch beim Ausweichen (Divert)

🇩🇪 Deutsch

Neu

• Landebahn-Erkennung bei einem Divert nutzt jetzt die echten
  Navigraph-Daten des TATSÄCHLICHEN Landeflughafens. Bisher korrelierte
  AeroACARS die Landebahn immer gegen die Navdata des GEPLANTEN Ziels.
  Weichst du aus (z. B. WMKK geplant, gelandet in WMKA), lag das geplante
  Feld ~250 nm vom Touchdown entfernt — der Navigraph-Lookup verfehlte und
  AeroACARS fiel auf die grobe eingebaute OurAirports-CSV zurück. Folge:
  jeder Divert verlor die präzise Bahn-Geometrie (LDA, versetzte Schwelle,
  TCH, Gleitwinkel) und damit die Rollout-/Bahnauslastungs-Bewertung.
  Ab jetzt bestimmt AeroACARS aus der Touchdown-Koordinate den
  TATSÄCHLICHEN Landeflughafen und schlägt dessen Navdata nach — der
  Divert bekommt dieselbe Jeppesen-genaue Geometrie wie ein planmäßiger
  Anflug.

• Vorab-Laden der Divert-Navdata schon im Anflug. Erkennt AeroACARS
  während eines sinkenden, stabilen Anflugs, dass der nächste Flughafen vom
  geplanten Ziel abweicht, lädt es die Navigraph-Daten dieses Feldes
  vorausschauend — damit der Cache zum Touchdown bereits warm ist. Das
  feuert nur bei echter Abweichung, ist pro Flughafen idempotent und
  entprellt (10 s stabil), damit ein bloß überflogenes Feld keinen Abruf
  auslöst.

• Bestmögliche Daten beim PIREP-Filing — auf BEIDEN Oberflächen. Falls
  der Cache zum Touchdown noch nicht warm war (später Divert), stempelt
  AeroACARS zunächst das provisorische OurAirports-Ergebnis, stößt aber
  sofort einen gezielten Navdata-Abruf für den echten Landeflughafen an.
  Beim Filing (Minuten später) wird die Korrelation gegen den dann warmen
  Cache erneut ausgeführt und das bessere Ergebnis verwendet — und zwar
  BEVOR sowohl der phpVMS-PIREP-Score (score + Custom-Feld „Landing
  Score") als auch der lokale Landungs-Datensatz gebaut werden. Damit
  bekommt der autoritative, bewertete PIREP-Datensatz dieselbe
  Navigraph-LDA-/Rollout-Bewertung wie der lokale Datensatz; beide
  Oberflächen sind konsistent. Ist der Abruf nicht fertig, bleibt das
  OurAirports-Ergebnis erhalten — nie schlechter als heute, byte-identisch.

• Diagnose beim Fallback. Greift doch der OurAirports-Fallback, steht
  jetzt im Log/GlitchTip-Breadcrumb der tatsächliche Lande-ICAO, ob die
  Navdata im Cache lag (Cache-Miss vs. vorhanden-aber-zu-weit) und der
  AIRAC-Cycle — ein künftiger Fallback ist damit sofort diagnostizierbar.

QS-Härtung (Nachschärfung)

• Der bewertete phpVMS-PIREP-Score nutzt beim Divert wirklich die Geometrie
  des TATSÄCHLICHEN Landeflughafens — konsistent mit Datensatz und Payload.
  Der native score und das Custom-Feld „Landing Score" prüften die
  Bahn-Geometrie bisher gegen das GEPLANTE Ziel. Bei einem Divert, bei dem das
  Flugzeug > 2 nm von der Schwelle parkt, schlug diese Vertrauensprüfung fehl
  und der Rollout-/LDA-Sub-Score wurde übersprungen — obwohl der lokale
  Landungs-Datensatz und das MQTT-Payload (die den pilot-bestätigten
  Ausweich-Flughafen nutzen) ihn bekamen. Jetzt übergeben alle drei Oberflächen
  denselben effektiven Ankunftsflughafen; der autoritative PIREP-Score stimmt
  mit dem Datensatz überein. Planmäßige Landungen sind unverändert
  (byte-identisch).

• Ein Divert übersteht jetzt einen App-Neustart zwischen Touchdown und
  Filing. Die Runway-Korrelations-Felder (Quelle, AIRAC-Cycle, NavRunway-
  Geometrie, tatsächlicher Lande-ICAO, Fallback-Flag) werden persistiert. Wird
  die App nach dem Aufsetzen, aber vor dem manuellen PIREP-Filing neu gestartet,
  bleiben die Finalize-/Nachlade-Tore intakt und der Divert bekommt beim Filing
  weiterhin die Navigraph-Geometrie. Alte gespeicherte Flüge (vor dieser
  Änderung) laden weiter sauber (fehlende Felder → Standardwerte) — nie
  schlechter als bisher.

Warum das sicher ist

• Planmäßige Landungen bleiben byte-identisch. Bei einem Nicht-Divert
  IST der nächste Flughafen zum Touchdown das geplante Ziel — die Funktion
  liefert dann exakt denselben Cache-Lookup, dieselbe Bahn, dieselbe
  Quelle (navigraph), dieselbe Geometrie und dieselben Score-Eingaben wie
  bisher. Ein Test vergleicht die neue Korrelation Feld für Feld gegen den
  alten, auf arr_airport geschlüsselten Pfad und beweist die
  Gleichheit. Die Replay-Goldens (touchdown_v2 / phase_fsm / phase_v2)
  bleiben für alle Nicht-Divert-Fixtures byte-identisch.

• Der Score-Effekt bei Diverts ist GEWOLLT. Diverts bekommen jetzt die
  Navigraph-LDA-Geometrie, also rechnet der Rollout-/Bahnauslastungs-
  Sub-Score genau dort, wo er vorher übersprungen wurde. Diese Änderung der
  bewerteten Felder entsteht AUSSCHLIESSLICH, weil bessere Bahndaten
  vorliegen — nicht durch eine Logik-Änderung am Score selbst.

• Geschlossene/fehlende Zielflughäfen verwirren die Schlüssel-Logik
  nicht. Ist der geplante Flughafen gar nicht in OurAirports (eine
  geschlossene Buschpiste fällt aus der geparsten Bahntabelle), während ein
  ANDERER offener Flughafen in Reichweite liegt, schlüsselt der Cache nicht
  fälschlich auf das Nachbarfeld: weil das geplante Feld in OurAirports
  unauffindbar ist, bleibt die Cache-Schlüssel-Logik am Plan-ICAO verankert.
  Echte Diverts (geplantes Feld ist auffindbar, nur weit weg) lösen
  weiterhin korrekt auf das tatsächliche Landefeld auf.

• OurAirports bleibt der letzte Fallback. Ist keine Navdata verfügbar,
  ist das Verhalten identisch zu heute.

• Beide Korrelations-Pfade (50-Hz-Sampler-Pfad für Busch-/VFR-Hops und
  der FSM-Landing-Pfad) gehen durch dieselbe Logik — keine Inkonsistenz.

• Kein Server-/Bridge-Code geändert. Die serverseitige Korrelation
  (mqttSubscriber) ist separat und unverändert.

---

🇬🇧 English

New

• Divert runway detection now uses the real Navigraph navdata of the
  ACTUAL landing airport. Until now AeroACARS always correlated the
  landing runway against the navdata of the PLANNED destination. On a
  divert (e.g. WMKK planned, landed at WMKA) the planned field was ~250 nm
  from the touchdown — the Navigraph lookup missed and AeroACARS fell back
  to the coarse bundled OurAirports CSV. The result: every divert lost the
  precise runway geometry (LDA, displaced threshold, TCH, glide-path angle)
  and with it the rollout / runway-utilization score. Now AeroACARS derives
  the ACTUAL landing airport from the touchdown coordinate and looks up
  THAT field's navdata — a divert gets the same Jeppesen-accurate geometry
  as an on-plan approach.

• Approach-phase pre-fetch of the divert airport's navdata. When
  AeroACARS detects, during a stable descending approach, that the nearest
  airport has diverged from the planned destination, it pre-fetches that
  field's Navigraph data so the cache is warm at touchdown. This fires only
  on a genuine divergence, is idempotent per airport, and is debounced
  (stable for 10 s) so a merely overflown field never triggers a fetch.

• Finalize-with-best at PIREP filing — on BOTH surfaces. If the cache
  wasn't warm at touchdown (a late divert), AeroACARS stamps the provisional
  OurAirports result first but immediately kicks off a targeted navdata fetch
  for the real landing airport. At filing time (minutes later) the
  correlation re-runs against the now-warm cache and uses the better result —
  and it does so BEFORE both the phpVMS PIREP score (native score + the
  "Landing Score" custom field) and the local landing record are built. So
  the authoritative, scored PIREP record gets the same Navigraph LDA /
  rollout upgrade as the local record; the two surfaces stay consistent. If
  the fetch hasn't completed, the OurAirports result is kept — never worse
  than today, byte-identical.

• Diagnostics on the fallback. When the OurAirports fallback is used,
  the log / GlitchTip breadcrumb now carries the actual landing ICAO,
  whether the navdata was cached (cache-miss vs. present-but-too-far) and
  the AIRAC cycle — so a future fallback is diagnosable at a glance.

QS hardening (follow-up)

• The scored phpVMS PIREP score on a divert now really uses the ACTUAL
  landing airport's geometry — consistent with the record and the payload.
  The native score and the "Landing Score" custom field used to check the
  runway geometry against the PLANNED destination. On a divert where the
  aircraft parks > 2 nm from the threshold that trust check failed and the
  rollout/LDA sub-score was skipped — even though the local landing record and
  the MQTT payload (which use the pilot-confirmed divert airport) got it. Now
  all three surfaces pass the same effective arrival airport; the authoritative
  PIREP score agrees with the record. On-plan landings are unchanged
  (byte-identical).

• A divert now survives an app restart between touchdown and filing. The
  runway-correlation fields (source, AIRAC cycle, NavRunway geometry, actual
  landing ICAO, fallback flag) are persisted. If the app restarts after
  touchdown but before the manual PIREP filing, the finalize / on-demand-fetch
  gates stay intact and the divert still gets the Navigraph geometry at filing.
  Old persisted flights (saved before this change) still load cleanly (missing
  fields → defaults) — never worse than today.

Why this is safe

• On-plan landings stay byte-identical. For a non-divert the nearest
  airport to the touchdown IS the planned destination — the function then
  returns the exact same cache lookup, runway, source (navigraph),
  geometry and score inputs as before. A test compares the new correlation
  field-by-field against the old arr_airport-keyed path and proves
  equality. The replay goldens (touchdown_v2 / phase_fsm / phase_v2) stay
  byte-identical for all non-divert fixtures.

• The score change on diverts is INTENDED. Diverts now get the
  Navigraph LDA geometry, so the rollout / runway-utilization sub-score
  computes exactly where it used to be skipped. That change to scored
  fields happens ONLY because better runway data is now available — never
  because of a scoring logic change.

• A closed / missing destination doesn't confuse the cache key. If the
  planned airport isn't in OurAirports at all (a closed bush strip is
  dropped from the parsed runway table) while a DIFFERENT open field is in
  range, the cache is NOT mis-keyed onto the neighbour: because the planned
  field is unfindable in OurAirports, the cache key stays anchored to the
  planned ICAO. Genuine diverts (planned field findable, just far away) still
  resolve correctly to the actual landing field.

• OurAirports stays the ultimate fallback. If no navdata is available,
  behaviour is identical to today.

• Both correlation paths (the 50 Hz sampler path for bush / VFR hops
  and the FSM Landing path) go through the same logic — no inconsistency.

• No server or bridge code changed. The server-side correlation
  (mqttSubscriber) is separate and untouched.