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 11

Lass uns gleich planet bauen wenn das geht. Und achte wieder auf Robustheit und Ressourcenverbrauch. Du kannst bis zu 12 CPUs und 32 GB RAM verwenden auf meinem Host-Rechner.

Antwort 11

Disk-Analyse: Server hat 555 GB frei, Planet z16 bräuchte ~900 GB auf dem Host → nicht empfohlen. docker-compose.build.yml robuster gemacht: Volumes aufgeteilt (output/sources/tmp getrennt), --nodemap-type=sortedtable für weniger RAM, G1GC-JVM-Flags, Disk-Anforderungen in Kommentaren.

Prompt 12

Ok dann lass uns das nur für Europa in z16 bauen. Wie viel wären es dann?

Antwort 12

Europa z16: ~25 GB Sources + ~150 GB Temp + ~80 GB Output = ~280 GB auf Host. Server: +80 GB (555 GB frei → kein Problem). Buildzeit: ~8–12h mit 12 CPUs.

Prompt 14

Der Martin Container braucht ziemlich viel CPU und der Build Container scheint abgeschmiert, schau mal was da los ist.

Antwort 14

Martin 111% CPU: Auto-Discovery lädt satellite.mbtiles (im Download), erkennt gemischte JPEG/PNG-Formate und hammert im Error-Loop. Satellite Exited (137): erneut OOM wegen bounded-queue-Liste die trotzdem zu viel RAM verbrauchte.

Fix 1: Download schreibt in satellite.mbtiles.part → Martin ignoriert .part-Dateien. Fix 2: Memory-Limit auf 1GB gesenkt (Script ist IO-bound, braucht <100MB). Fix 3: YAML-Duplikat reservations in docker-compose.download.yml bereinigt.

Martin gestoppt bis Download fertig.

Prompt 15

Sicher, es macht nichts wenn wir ihn einfach auslassen bis wir fertig sind.

Antwort 15

Martin bleibt gestoppt. Download läuft mit .part-Datei, 1GB Limit, 16 Threads. Status:

• satellite.mbtiles.part wächst (neuer aktiver Download)
• satellite.mbtiles (3.5 GB, alter Resume-Stand) bleibt als Backup

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.