# Geoportal Continuous Improvement — Mega Prompt Use this prompt to start a new session focused on geoportal tile serving improvements. --- ## Context Prompt (copy-paste to Claude) ``` Scopul acestei sesiuni este imbunatatirea continua a tile serving-ului pentru modulul Geoportal din ArchiTools. Citeste aceste fisiere INAINTE de orice: - CLAUDE.md (project conventions) - geoportal/TILE-SERVER-EVALUATION.md (current architecture + roadmap) - src/modules/geoportal/components/map-viewer.tsx (MapLibre + PMTiles integration) - martin.yaml (Martin tile server config) - docker-compose.yml (infrastructure stack) - scripts/rebuild-overview-tiles.sh (PMTiles generation pipeline) - src/app/api/geoportal/monitor/route.ts (monitoring API) - src/app/(modules)/monitor/page.tsx (monitoring dashboard) ## Arhitectura curenta (2026-03-28): Pipeline: Browser → PMTiles (MinIO, z0-z18, ~1-2 GB) | Martin (PostGIS) doar pentru gis_terenuri_status + gis_cladiri_status Cache: nginx tile-cache (7d TTL) in fata Martin | Browser cache 24h | PMTiles servit direct din MinIO Stack: - PMTiles: overview.pmtiles pe MinIO (10.10.10.166:9002/tiles/overview.pmtiles) - nginx tile-cache: port 3010, proxy_cache 2GB, 7d TTL - Martin v1.4: port intern 3000, config baked in image, pool_size 8 - tippecanoe Docker: one-shot rebuild, profiles: ["tools"] - N8N webhook: auto-rebuild dupa weekend deep sync Rebuild PMTiles: ~45-60 min (565K+ features, z0-z18) Server: VM satra (10.10.10.166), 6 CPU, 16 GB RAM, Docker, Portainer CE IMPORTANT: - NEXT_PUBLIC_* vars TREBUIE declarate ca ARG+ENV in Dockerfile (altfel webpack nu le vede) - Portainer CE nu monteaza fisiere din repo — bake configs in Docker images - Dupa schimbari la Dockerfile/NEXT_PUBLIC_: docker compose build --no-cache architools Comenzi server (SSH bulibasa@10.10.10.166): cd /tmp/ArchiTools && git pull && docker compose --profile tools build tippecanoe && docker compose --profile tools run --rm tippecanoe docker compose build --no-cache architools && docker compose up -d architools bash /tmp/ArchiTools/scripts/warm-tile-cache.sh http://10.10.10.166:3010 Monitor dashboard: https://tools.beletage.ro/monitor N8N: http://n8n.beletage.ro (workflow "PMTiles Rebuild") npx next build TREBUIE sa treaca dupa fiecare schimbare. ``` --- ## Checklist periodic (lunar): ### 1. Check MLT Production Readiness ``` Verifica daca Martin suporta generare MLT din PostGIS (nu doar servire din MBTiles). Cauta: - Martin releases: https://github.com/maplibre/martin/releases - Martin MLT PR: https://github.com/maplibre/martin/pull/2512 - PostGIS MLT: cauta "ST_AsMLT" in PostGIS development - MapLibre GL JS MLT: https://maplibre.org/maplibre-tile-spec/implementation-status/ Daca Martin poate genera MLT din PostGIS live: 1. Testeaza pe un layer (gis_terenuri) cu encoding: "mlt" in map-viewer 2. Compara tile sizes MVT vs MLT 3. Daca merge, aplica pe toate layerele Martin Status curent (2026-03-28): NU e viabil. Martin doar serveste MLT pre-generat, nu transcodeaza din PostGIS. ``` ### 2. mvt-rs Parallel Evaluation ``` Evalueaza mvt-rs ca alternativa Martin pentru deployment multi-tenant. Prompt gata de folosit: "Deployeaza mvt-rs v0.16+ in parallel cu Martin pe ArchiTools. Context: - PostgreSQL: 10.10.10.166:5432, db architools_db, user architools_user - Martin actual: martin.yaml cu 9 surse PostGIS (EPSG:3844) - Docker stack: Portainer CE, Traefik v3 - Scopul: per-layer access control pentru clienti externi Steps: 1. Adauga mvt-rs in docker-compose.yml pe port 3011 2. Configureaza aceleasi layere ca martin.yaml 3. Test: toate proprietatile apar in MVT? Performance vs Martin? 4. Admin UI: creeaza user test, asigneaza permisiuni per layer 5. Decision matrix: cand trecem de la Martin la mvt-rs NU modifica setup-ul Martin existent. Evaluare paralela doar. mvt-rs repo: https://github.com/mvt-proj/mvt-rs Citeste CLAUDE.md si geoportal/TILE-SERVER-EVALUATION.md inainte." ``` ### 3. PMTiles Rebuild Optimization ``` Daca rebuild dureaza >60 min sau fisierul >3 GB: - Evalueaza tile-join pentru rebuild partial (doar layerul modificat) - Evalueaza --no-tile-size-limit vs --drop-densest-as-needed trade-off - Evalueaza split: un PMTiles per UAT sincronizat (rebuild doar orasul modificat) - Evalueaza cron nightly vs rebuild per sync event ``` --- ## Known Issues & Limitations - tippecanoe `--drop-densest-as-needed` poate pierde features in zone dense la zoom mic - PMTiles data e statica — parcele noi nu apar pana la rebuild - MinIO CORS headers necesita Range + Content-Range exposed - Martin `pool_size: 8` — nu creste fara upgrade PostgreSQL - Portainer CE nu injecteaza env vars la build — toate in docker-compose.yml