# Bekannte Grenzen des lokalen Radar-Nowcastings (v1.10.0) Diese Seite listet **ausdrücklich und ehrlich** alle bekannten Einschränkungen des in v1.10.0 eingeführten Nowcastings. Für die technische Herleitung siehe [radar-nowcasting-architecture.md](radar-nowcasting-architecture.md) "Bekannte Grenzen" und [radar-cell-tracking.md](radar-cell-tracking.md). ## Datengrundlage - **Keine numerischen Niederschlagswerte.** Die verwendete DWD-WMS-Quelle liefert gerenderte Bildpixel, keine physikalischen Messwerte. Jede Intensitätsangabe dieses Features ist eine **Klasse** (leicht/mäßig/stark/sehr stark), abgeleitet aus der amtlichen Legendenfarbe des jeweiligen Bildes — niemals ein Millimeterwert. - **Legendenausrichtung nicht produktiv verifiziert.** Ob die schwächste Legendenfarbe am Anfang oder Ende der erkannten Farbskala liegt (`NOWCAST_LEGEND_DIRECTION`), wurde bisher nicht gegen ein echtes, live abgerufenes `GetLegendGraphic`-Bild verifiziert. Eine falsch herum erkannte Skala würde "leicht" und "sehr stark" vertauschen. - **Keine Blitzdaten.** Es wurde keine bereits rechtmäßig nutzbare, im Projekt dokumentierte Blitzquelle gefunden. Blitzaktivität fließt daher nicht in die Einschätzung ein (ausführliche Quellenprüfung samt geprüfter Kategorien: siehe [lightning-source-evaluation.md](lightning-source-evaluation.md), v1.18.0). ## Zellerkennung und Tracking - **Grobe räumliche Auflösung.** Analysebilder sind bewusst klein (320×320px über ~110 km) — sehr kleine, kurzlebige Einzelzellen können übersehen oder mit benachbarten Zellen verschmolzen werden. **Klarstellung (Radar-2.0-Block, bestätigter Audit-Befund)**: dieselbe Grenze gilt auch für die im Radar-Bildschirm dargestellten PNGs, unabhängig von der angeforderten Pixelgröße (bis 1536px, siehe `scripts/lib/radar-image-cache-lib.js`) - die zugrunde liegende DWD-WMS-Ebene (`dwd:Radar_rv_product_1x1km_ger`) liefert ein natives Gitter von rund 1×1 km. Ein höher aufgelöst angefordertes Bild lässt den DWD-Dienst nur staerker interpolieren (mehr Pixel, nicht mehr echte Information) - "Pixeligkeit" bei den nahen Kartenausschnitten ist damit primär eine Grenze der Quelldaten, nicht der Client-Anfrage. - **Hauptphase/Ende/Folgezellen sind geometrische Näherungen, keine Blitz- oder Modellsignale.** Seit dem Radar-2.0-Block liefert das Nowcasting zusätzlich ein Hauptphasen-Zeitfenster und einen groben Folgezellen-Hinweis (siehe [radar-nowcast-main-phase.md](radar-nowcast-main-phase.md)) - beide ausschließlich aus bereits vorhandenen Radar-Trackingwerten (Fläche, Geschwindigkeit, Distanz) abgeleitet, ohne jede Blitzbeobachtung. - **Teilungs-/Vereinigungserkennung ist eine Heuristik**, kein exaktes Verfahren — sie erkennt räumliche Nähe zwischen einem Match und einer unzugeordneten Zelle, kann aber nicht sicher zwischen "echter Teilung" und "zwei unabhängigen, zufällig nahen Zellen" unterscheiden. - **Zielbereich-Radien (10/30/80 km) sind ein dokumentierter Startpunkt**, keine anhand echter Wetterlagen kalibrierte Größe. - **Nur die letzten `NOWCAST_MAX_FRAMES` (Standard 6) Beobachtungsframes** werden verwendet — eine länger zurückliegende Entwicklung fließt nicht ein. ## Ankunftsfenster und Konfidenz - **Nie ein exakter Zeitpunkt**, immer ein Fenster mit ±35 % Unsicherheit um die Punktschätzung. - **Bei geringer Konfidenz gibt es überhaupt kein Zeitfenster** — auch wenn eine grobe Annäherung erkennbar ist. - **Die Konfidenzstufen (hoch/mittel/niedrig) wurden noch nicht systematisch kalibriert.** Seit v1.15.0 gibt es dafür zusätzlich einen numerischen Konfidenzwert (0–1, siehe [nowcast-validation.md](nowcast-validation.md) "Konfidenzwert") und eine Kalibrierungsauswertung (siehe [nowcast-calibration.md](nowcast-calibration.md), inkl. Brier Score) — ob "hoch" tatsächlich deutlich zuverlässiger ist als "niedrig", lässt sich damit auswerten, sobald genügend reale Fälle vorliegen. Bislang (Einführung der Infrastruktur) ist das noch nicht der Fall. ## Was (noch) fehlt - **Validierung/Backtesting: Infrastruktur vorhanden, reale Stichprobe noch klein (seit v1.15.0).** Seit v1.15.0 existiert eine vollständige, dateibasierte Validierungs-/Backtesting-/ Kalibrierungsinfrastruktur (siehe [nowcast-validation.md](nowcast-validation.md), [nowcast-backtesting.md](nowcast-backtesting.md), [nowcast-calibration.md](nowcast-calibration.md)): jeder berechnete Nowcast wird unveränderlich archiviert, später automatisch anhand tatsächlich archivierter Radarframes verifiziert (Treffer/Fehlalarm/verpasst/korrekt negativ/nicht bewertbar) und in Klassifikations-, ETA- und Kalibrierungskennzahlen ausgewertet. **Zum Zeitpunkt der Einführung liegen jedoch praktisch keine realen Fälle vor** (die Historie startet leer) — alle Kennzahlen sind entsprechend anfangs `null`/nicht aussagekräftig, die Monitoring-Oberfläche zeigt das ehrlich an, statt Zahlen vorzutäuschen. Ein [Freigabegate](nowcast-notification-gate.md) berechnet zusätzlich, ob die Datenlage jemals für eine Benachrichtigungsfunktion ausreichen würde — es aktiviert nichts von selbst und ist mangels Daten aktuell "nicht bestanden". - **Keine Push-/E-Mail-Benachrichtigungen aus dem Nowcasting** — bewusst nicht aktiviert (siehe Anforderung Abschnitt 14). Eine spätere Benachrichtigungsfunktion würde einen eigenen Meilenstein mit Fehlalarmtests, Mindestkonfidenz, Cooldown und klarer Abgrenzung zu amtlichen Warnungen benötigen. - **Keine visuelle Kartendarstellung** der erkannten Zelle/Zugbahn/des Korridors — nur die textliche Zusammenfassung. Laut Auftrag ausdrücklich optional, bewusst zurückgestellt. - **Kein VPS-Produktivbetrieb** dieses Features in diesem Arbeitsschritt. ## Was die Karte niemals behauptet - Keine exakte Ankunftszeit ("trifft um HH:MM Uhr ein"). - Keine amtliche Warnung oder Warnstufe. - Keine garantierte Erkennung — ein tatsächlich herannahendes Gewitter kann trotzdem als "keine relevante Annäherung" erscheinen, wenn die Datenlage (zu wenige/unregelmäßige Frames, instabile Zugbahn) keine belastbare Aussage zulässt. Die App zeigt dann ehrlich "nicht genügend Radarbilder" statt eine unsichere Aussage zu erzwingen.