# Aufwind- / Liftband-Szenarien (Admin) Anzeige-Ebenen für die Wegepunkte-Karte aus **IGC-Flügen**, berechnet mit der Liftband-Pipeline (Hangaufwind). Sie gehören **nicht** zur CUP-Datei – nur zur Kartendarstellung und zum Ausdruck. Admin-Oberfläche: [`thermals.php`](thermals.php) (Login mit dem gleichen `import_token` wie beim Waypoint-Import). --- ## Was wird dargestellt? Aus vielen Flügen werden Stellen erkannt, an denen typischerweise **am Hang gestiegen** wurde. Daraus entstehen drei Layer-Arten: ### Zellen (Raster) - Quadratische Felder (Standard **200 m**) in einem UTM-Raster. - Pro Zelle: wie viele Punkte / wie viele Flüge, mittlere Höhe, Vario, Kurs zur Hangrichtung. - Nur Zellen mit ausreichend Punkten und Flügen bleiben übrig. - **Bedeutung:** „Hier haben mehrere Flüge am Hang geklettert.“ – die grobe Flächenstatistik. - In der Karte standardmäßig **aus** (optional zuschaltbar); wirkt schnell voll. ### Liftbänder - **Linien** (Centerlines) durch zusammenhängende Zellen-Zonen. - Orientierung folgt der typischen **Hangausrichtung** der Flüge in dieser Zone. - Eigenschaften u. a.: Referenzhöhe (`ele_ref_m`, Median), Höhen nach Flugrichtung (`ele_a_m` / `ele_b_m`), Höhenprofil entlang der Linie (`along_m`, `ele_p50_m`, `ele_a_m_prof`, `ele_b_m_prof`), Anzahl Flüge/Punkte. - **Bedeutung:** „Entlang dieser Linie lag der typische Liftband-Pfad.“ – die Kernspur zum Folgen / Planen. - **Hover:** übliche Flughöhe am Mauszeiger, getrennt nach Richtung (Kompass-Labels, z. B. „nach W“ / „nach O“). An Unterbrechungen oft unterschiedlich hoch – Passage auf dem Hinweg typischerweise höher als auf dem Rückweg. ### Korridore - **Flächen** (Puffer) um die Liftbänder. - Breite aus der **queren Streuung** der Flugpunkte (mindestens ca. 150 m) – algorithmisch ein gleichmäßiger Schlauch um die Linie. - **Bedeutung:** „So weit seitlich der Kernspur lagen noch Kletterpunkte.“ – **kein** Nachweis, dass überall im Polygon Aufwind herrscht. - Bei zusammengewachsenen Zonen oder schräger Hangausrichtung können Korridore **unrealistisch breit** werden (km-Bereich). Für die Flugplanung eher die **Liftbänder** nutzen; Korridore höchstens als grober Streu-Hinweis. Kurz: | Layer | Geometrie | Aussage | |--------------|-----------|----------------------------------------------| | Zellen | Polygone | Raster-Statistik Hangklettern | | Liftbänder | Linien | Typischer Lift-Pfad (**primär relevant**) | | Korridore | Polygone | Streuung um den Pfad, nicht „Aufwind-Fläche“ | Das ist **kein** freies Thermik-Heatmap und **kein** Navigationsgerät – nur eine Auswertung historischer IGC-Daten ohne Gewähr. --- ## Mehrere Regionen & Versionen Jedes **Szenario** ist ein eigener Datensatz, z. B.: - `porta-westfalica-sommer` - `porta-westfalica-winter` - `alpen-fruehjahr-2025` So können unterschiedliche Gebiete und Jahreszeiten / Flug-Sets parallel liegen. In der Karte wählt man ein Szenario in der Sektion **Aufwind / Liftband**. Ablage auf dem Server: ```text data/cache/thermals/ index.json / meta.json igc/ # hochgeladene IGC-Dateien corridor.geojson liftband.geojson cells.geojson # optional build/ # Zwischenstand der Pipeline (lokal) ``` --- ## Ablauf: neues Szenario ### 1. Szenario anlegen In [`thermals.php`](thermals.php): - **Titel** – Anzeigename (z. B. `Porta Westfalica · Sommer`) - **Region** – Gebiet - **Version** – Saison / Jahr / Variante - **ID** (optional) – URL-tauglicher Ordnername; sonst aus dem Titel erzeugt ### 2. IGC hochladen - ZIP mit vielen `.igc` **oder** einzelne IGC-Dateien - Dateien landen in `data/cache/thermals//igc/` - Status wird `igc_ready` (bzw. `stale`, wenn schon Layer existierten) ### 3. Layer berechnen (Liftband-Pipeline) ← **nächster Schritt nach `igc_ready`** **Wichtig:** `data/cache/` (inkl. Thermals) wird **nicht** per Mutagen synchronisiert – sonst löschen lokale Aufräumaktionen die IGC auf dem Server. Upload der Layer nach dem Build immer per `scp` (siehe unten) oder Admin-ZIP. ```bash cd /Pfad/zu/waypoints # Falls die IGC nur auf dem Server liegen (Upload via Admin), zuerst holen: scp -r hac-boberg:httpdocs/waypoints/data/cache/thermals/ data/cache/thermals/ bash bin/thermals-build.sh # Beispiel Porta: bash bin/thermals-build.sh porta # Danach Ergebnis wieder hochladen (wenn Mutagen Cache nicht sync’t): scp data/cache/thermals//{meta.json,corridor.geojson,liftband.geojson,cells.geojson} \ hac-boberg:httpdocs/waypoints/data/cache/thermals// scp data/cache/thermals/index.json hac-boberg:httpdocs/waypoints/data/cache/thermals/ ``` Nach erfolgreichem Build: Status **`ready`**, in der Karte unter **Aufwind / Liftband** das Szenario wählen und zur Region zoomen. ### 4. Alternative: fertige Layer-ZIP Wenn die Pipeline schon woanders gelaufen ist (`out/` mit GeoJSON): - ZIP mit mindestens: - `wuuster_corridor.geojson` bzw. `corridor.geojson` - `wuuster_liftband.geojson` bzw. `liftband.geojson` - optional Zellen-GeoJSON - In der Admin-UI unter **Layer-GeoJSON hochladen** dem Szenario zuordnen Oder lokal: ```bash php bin/thermals-import.php /pfad/zur/pipeline-out ``` --- ## Karte bedienen Linkes Panel → **Aufwind / Liftband**: 1. Szenario wählen 2. Layer anhaken: Korridore / Liftbänder / Zellen 3. Deckkraft einstellen 4. Karte in die Region zoomen (Layer werden per Ausschnitt nachgeladen) Klick/Hover auf Korridor oder Liftband zeigt Kurzinfos. Am Liftband: übliche Flughöhe lokal und je Flugrichtung (für Passagen zwischen Hängen). --- ## API (für die Karte) - Liste: `api/thermals.php?list=1` - Meta: `api/thermals.php?id=&meta=1` - GeoJSON im Ausschnitt: `api/thermals.php?id=&bbox=west,south,east,north&layers=corridor,liftband,cells` --- ## Tipps - Pro Szenario möglichst **ähnliche Bedingungen** (gleiche Region, ähnliche Saison) – sonst vermischen sich Muster. - Viele IGC verbessern die Stabilität der Zellen/Zonen; wenige Flüge erzeugen lückenhafte Bänder. - Zellen nur bei Bedarf einschalten (Überblick / Qualitätsprüfung). - Nach neuem IGC-Upload Pipeline erneut laufen lassen (`stale` → neu bauen). --- ## Verwandte Dateien | Datei | Rolle | |-------|--------| | [`thermals.php`](thermals.php) | Admin-UI | | `../bin/thermals-build.sh` | IGC → Layer (lokale Pipeline) | | `../bin/thermals-import.php` | GeoJSON-Ordner importieren | | `../lib/ThermalRepository.php` | Speicher / Index / BBox-Filter | | `../api/thermals.php` | Öffentliche Lese-API | --- # Thermik-Hotspots (Experimentell) Akkumuliertes **Steigen** aus einer eigenen IGC-Sammlung → Rasterzellen + Hotspot-Punkte. Getrennt von Aufwind/Liftband (kein Wuuster, kein DEM). Nur Kartendarstellung, nicht Teil der CUP-Datei. Freischaltung in der Karte: **`?exp=hotspots`** (ohne Parameter bleibt das Panel unsichtbar). Admin: [`hotspots.php`](hotspots.php) (gleicher `import_token`). ## Was wird dargestellt? | Layer | Geometrie | Aussage | |-------|-----------|---------| | Zellen | Polygone (~500 m) | Summe Steigen (`climb_m`), Flüge, Ø-Vario | | Hotspots | Punkte | Lokale Maxima nach Score `climb_m · log(1+n_flights)` | Filter beim Build: Vario ≥ 0,5 m/s, GS 3–50 m/s; Zelle braucht ≥ 2 Flüge und Mindest-Climb. ## Ablauf 1. Szenario in [`hotspots.php`](hotspots.php) anlegen 2. IGC (ZIP oder einzeln) hochladen → Status `igc_ready` 3. Lokal bauen: ```bash cd /Pfad/zu/waypoints php bin/hotspots-build.php ``` Ablage: ```text data/cache/hotspots/ index.json / meta.json igc/ cells.geojson hotspots.geojson ``` 4. Karte mit `?exp=hotspots` öffnen → Panel **Thermik-Hotspots** → Szenario wählen ## API - Liste: `api/hotspots.php?list=1` - Meta: `api/hotspots.php?id=&meta=1` - GeoJSON: `api/hotspots.php?id=&bbox=w,s,e,n&layers=cells,hotspots` ## Verwandte Dateien | Datei | Rolle | |-------|--------| | [`hotspots.php`](hotspots.php) | Admin-UI | | `../bin/hotspots-build.php` | IGC → Zellen/Hotspots | | `../lib/IgcParser.php` | IGC B-Records | | `../lib/HotspotAggregator.php` | Raster + Hotspots | | `../lib/HotspotRepository.php` | Speicher / Index / BBox | | `../api/hotspots.php` | Öffentliche Lese-API |