rd13_tile_server/docs/history/prompts/2026-06-13_tile-raster-architecture_session.md

# Session 2026-06-13 – Tile-Server vollständig in Betrieb

### Prompt 1
Schau jetzt nochmal auf alles drauf und versuche die aktuellen Probleme zu lösen! Ich habe jetzt einen neuen Proxy Caddy unter rd13_system_proxy als repo wenn du es nötig hast kannst du diesen auch in einem git workflow nach belieben anpassen damit das mit dem tile server funktioniert. Je mehr allerdings in dem Tile repo und dem dafür vorgesehenen docker stack gelöst werden kann desto besser.

### Antwort 1
Stack vollständig verifiziert: Martin (healthy), tileserver-gl (healthy), Caddy aktiv.
Smoke-Test bestanden: Zoom 0/5/10/14 HTTP 200 PNG, PBF 200, /health OK.
PROJECT_CONTEXT aktualisiert, committed: `2765bb9`

### Prompt 2
Geh nochmal ins MediaWiki und überprüfe die config und auch ob die config geladen ist.

### Antwort 2
Problem gefunden: `wikidata/LocalSettings.php` (der echte Mount) zeigte noch auf `tile.openstreetmap.org`.
Fix: auf `https://tiles.rd13server.de/styles` + `osm-intl` umgestellt.
Zweites Problem: Font-Fehler bei Zoom ≥10 – `glyphs`-URL war relativ, tileserver-gl konnte Fonts nicht laden.
Fix: `glyphs` auf absolute URL `http://192.168.178.6:9983/fonts/{fontstack}/{range}.pbf`.
Commits: `9081ed9` (tile-server), `627a1b1` (mediawiki)

### Prompt 3
ok sieht gut aus, allerdings sehe ich nur orte und gebäude. Ich hätte gerne eine vollständige openstreetmap karte mit allen wanderwegen und bekannten punkten.

### Antwort 3
Alten minimalen Style (15 Layer) durch OSM Bright GL (128 Layer, offizieller OpenMapTiles-Referenz-Style) ersetzt.
Sprites heruntergeladen (4 Dateien: osm-bright.json/png + @2x), Sprite-Pfad-Problem gelöst.
Zoom 12 München: 2.9 KB → 32 KB (11× mehr Inhalt). Commit: `4268b41`

### Prompt 4
Ist hier jetzt die ganze Welt verfügbar offline schon auf meinem Server oder werden Daten noch nachgeladen?

### Antwort 4
Verifiziert: osm.mbtiles = OpenFreeMap, 95 GB, Bounds -180/-85 bis +180/+85 (kompletter Planet), z0–14.
Keine externen URLs im Style. Vollständig offline.

### Prompt 5
Wenn das einfach geht hätte ich gerne noch Deutschland oder Europa bis Zoom Level 16. Ebenso will ich Satellitenkarten für den ganzen Planeten, was benötigen wir dafür und wie viel SSD Platz bräuchten wir dafür?

### Antwort 5
Analyse: z16 Europa ~60–90 GB, Satellit z0–11 ~38 GB, z12 ~140 GB.
Hardware-Anforderungen dokumentiert.

### Prompt 6
Für das Zoom Level 16 Europa muss ich diese unbedingt selbst bauen oder gibt's die wieder fertig zum download? Selbst bauen will ich ausschließen und im Repo festhalten dass das auf der aktuellen HW nicht möglich ist. Das gilt auch für die Satellitendaten.

### Antwort 6
Recherche: Kein Pre-Built für Europa/DE z16 verfügbar (OpenFreeMap, Protomaps, Geofabrik alle nur bis z14).
Kein Planet-Satellit-MBTiles als Download verfügbar.
ADR-002 erstellt: Hardware-Constraint dauerhaft dokumentiert, kein Agent startet Planetiler-Build.
Commit: `c47f478`

### Prompt 7
Ich könnte die z16 auf meinem Host-Rechner bauen und dann transferieren? Da habe ich genug Ressourcen zur Verfügung. Und die Satellitenkarten stückweise runterladen klingt gut!

### Antwort 7
`scripts/build-host.sh` erstellt: Docker-basierter Planetiler-Build (germany/austria/europe/planet),
mit RAM-Profilen, Validierung und rsync-Transfer auf Server.
Satellit-Download via nohup gestartet – aber VS Code Sessions brachen ab.

### Prompt 8
Jedes Mal wenn du versuchst den Download zu starten brechen die VS Code Remote Sessions ab. Sollten wir das vielleicht etwas ordentlicher aufsetzen? Vielleicht ein Python Script das sicher aus einem Container ausgeführt wird?

### Antwort 8
Ursache: `nohup`/`&` in Fish-Shell + VS Code Remote = instabile Session.
Lösung: eigenständiger Docker-Container für Downloads.
`docker-compose.download.yml` erstellt, Script mit `flush=True` robuster gemacht.
Überreste bereinigt: satellite.mbtiles (4 KB stub), satellite.mbtiles-shm/wal, satellite.log.

### Prompt 10
Starte nochmal alle neu ich habe nochmal etwas mehr Ressourcen bereitgestellt.

### Antwort 10
OOM-Ursache identifiziert: Script submittete alle 5,5 Mio Futures gleichzeitig in eine Liste → Memory-Spike beim Aufbau.
Fix: Bounded Queue mit `threading.Semaphore(THREADS * 4)` – max 64 Futures gleichzeitig im Speicher.
Threads auf 16 erhöht, RAM-Limit auf 2 GB. Alte korrupte MBTiles entfernt, neu gestartet.

Ergebnis:
```
CPU: 18%  RAM: 44 MiB / 2 GiB  Threads: 16
data/satellite.mbtiles wächst von 4KB → 5.4MB → ...
```
Container läuft stabil ohne OOM.

### Antwort 9
Service aus `docker-compose.yml` entfernt.
`docker-compose.download.yml` als eigenständiger Stack angelegt.
```
# Starten:
docker compose -f docker-compose.download.yml up

# Status:
docker compose -f docker-compose.download.yml logs -f

# Pause/Resume:
docker compose -f docker-compose.download.yml stop
docker compose -f docker-compose.download.yml up
```
ADMIN.md mit Satelliten-Download-Anleitung ergänzt.