72 lines
3.6 KiB
Markdown
72 lines
3.6 KiB
Markdown
|
# 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:**
|
|||
|
|
|
|||
|
|
1. **ADR-001 erstellt: [docs/adr/001-martin-tileserver-gl-stack.md](../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)
|
|||
|
|
|
|||
|
|
2. **ADR-Template erstellt: [docs/adr/000-template.md](../docs/adr/000-template.md)**
|
|||
|
|
- Nygard-Format: Status, Context, Decision, Consequences, Alternatives
|
|||
|
|
|
|||
|
|
3. **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
|
|||
|
|
```
|