Session 2026-06-12 – Tile-Server Raster-Architektur

Prompt 1

Ich habe die eigentliche Ursache gefunden: dein Tile-Server liefert nur Vektor-Tiles (PBF) und keine gerenderten PNG-Styles für Kartographer. Ich teste jetzt einen sofort funktionierenden Raster-Fallback-Pfad, damit Karten in der UI wieder erscheinen. Was müssen wir hier tun damit das geht?

Antwort 1

Diagnostiziert, dass Martin ohne PNG-Rendering nicht für Kartographer ausreicht. Analyzed:

Martin serviert nur PBF-Vektor-Tiles
Kartographer erwartet PNG (raster) oder MapLibre GL Styles (mit client-side Rendering)
osm.mbtiles ist vorhanden, aber keine Style-Definitionen in /data/styles/

Empfohlen: Schneller Fallback mit Nginx-Proxy zum OSM.org Upstream ODER lokales Raster-Rendering mit tileserver-gl.

Dokumentation gelesen: docker-compose.yml, martin.yaml, mediawiki-config.php, api-endpoints.md, REQUIREMENTS.md

Prompt 2

Dauerhaft sauber: eigenen Raster-Renderer ergänzen (z. B. tileserver-gl oder openmaptiles-Server) und dieselbe Kartographer-URL-Struktur lokal bedienen. las uns das planen

Antwort 2

High-Level Plan erarbeitet:

Martin bleibt für Vektor-API und interne Nutzung
Raster-Renderer (tileserver-gl) neu hinzufügen
Reverse Proxy: /osm-intl/{z}/{x}/{y}.png → tileserver-gl
MediaWiki unabhängig von externen Tile-Servern

Geplant: 6 Arbeitspakete, Abnahmekriterien, Umsetzungsschätzung.

Alternatives Analyzed: OpenMapTiles Server (overengineered, für euch jetzt nicht nötig), tileserver-gl (optimal für static 2–4×/Year Updates).

Prompt 3

was ist der unterschied zwischen open map tiles server und martin. Erkläre mir high level warum ich beide brauche was nur der eine und nur der andere kann und warum es besser ist beide zu haben was sind die jeweiligen aufgaben?

Antwort 3

Detaillierte Vergleichstabelle erstellt:

Aspekt	Martin	OpenMapTiles Server
Kategorie	Tile-Distributer	OSM-Daten-Pipeline
Eingabe	MBTiles/PMTiles (fertig)	Rohe OSM-Daten oder Shapefile
Was es macht	Vektor/Raster aus DB auslesen + HTTP servieren	OSM importieren → Vektor-Layer definieren → Rendering-Regeln → Tiles generieren
Stack-Größe	~50 MB, single binary	PostGIS + Rendering-Engine + Tile-Generator → GB

Konklusiv: Martin + tileserver-gl jetzt optimal. OpenMapTiles Server nur nötig wenn Live-OSM-Updates erforderlich (zukünftig, nicht jetzt).

Prompt 4

ok lass und das im repo als adr festhalten aber wir entscheiden uns für martin und tileservergl für den anfang, wenn ich in dem stack trotzdem stiles und karten anpassen kann und das updaten der karten 2-4 Mal im jahr einfach möglich ist.

Antwort 4

Architektur-Entscheidung dokumentiert:

ADR-001 erstellt: docs/adr/001-martin-tileserver-gl-stack.md
- Status: Accepted
- Decision: Martin (Vektor) + tileserver-gl (Raster PNG)
- Rationale: niedrige Komplexität, Style-Flexibilität, 2–4x/Year Update-Zyklus passend
- Alternatives analyzed: OpenMapTiles Server (deferred), External proxy (violates ToS)
- Future ADRs: ADR-002 (Live OSM Pipeline), ADR-003 (Horizontal Scaling)
ADR-Template erstellt: docs/adr/000-template.md
- Nygard-Format: Status, Context, Decision, Consequences, Alternatives
REQUIREMENTS.md aktualisiert
- Architektur-Übersicht hinzugefügt
- Link zu ADR-001
- Explizit dokumentiert: Styles anpassbar, 2–4x/Year Update-Workflow

Files staged & ready for commit:

A  docs/adr/000-template.md
A  docs/adr/001-martin-tileserver-gl-stack.md
M  docs/requirements/REQUIREMENTS.md

3.6 KiB Raw Blame History Unescape Escape