6.7 KiB
Prompt Claude Code (WebApp carto KML/GeoJSON + fonds type Google Earth, Docker)
Tu es Claude Code. Objectif : développer une webapp self-hosted moderne (UI gruvbox dark vintage) installable en Docker, qui affiche une carte avec fonds satellite / hybride / vecteur, permet d’importer des fichiers locaux KML et GeoJSON, puis d’éditer/ déplacer des points et modifier leurs attributs (texte/HTML), en affichant aussi les images intégrées (ex : dans les descriptions KML ou champs GeoJSON).
Contraintes & exigences
Projet “production-ready” minimal, mais extensible.
Import local via navigateur (drag&drop + bouton).
Aucune dépendance à Google Earth desktop : tout doit marcher via navigateur.
Style : gruvbox dark vintage (thème cohérent, contrastes, lisibilité).
Docker : un docker-compose.yml pour lancer l’ensemble.
Stockage : persistance des datasets importés + historique des modifications (versioning simple).
Sécurité : accès LAN seulement (pas d’auth pour v1), mais structure prête pour ajout futur.
Performance : datasets raisonnables (ex: 5k–50k points). Prévoir clustering/virtualisation si besoin.
Architecture attendue
Frontend : SPA moderne (TypeScript), composants UI, panneau latéral, import, édition.
Backend : API REST (Python FastAPI) pour persister les couches/datasets, servir les fichiers, gérer versions.
Stockage : SQLite + stockage fichiers sur volume (KML/GeoJSON originaux + export).
Export : permettre d’exporter la couche éditée en GeoJSON (v1) + KML (v2).
Tests : au moins tests unitaires backend (API import/validation) + tests frontend basiques (import parsing).
Fonctionnalités détaillées (MVP)
Carte & fonds
Afficher une carte plein écran.
Proposer 3 fonds : “Satellite”, “Hybride”, “Vecteur”.
Utiliser un fournisseur de tuiles compatible (pas besoin d’API key au début si possible), mais prévoir la configuration via .env (URL templates, attribution).
Afficher l’attribution correctement.
Import fichiers
Import KML local (fichier .kml / .kmz si simple).
Import GeoJSON local.
À l’import : parser, valider, normaliser (projection WGS84).
Convertir en “couches” internes : points / lignes / polygones.
Conserver le “raw” original pour re-téléchargement.
Edition
Sélection sur la carte (clic) + liste des features dans un panneau.
Déplacement des points (drag) + undo/redo (au moins undo 1 niveau).
Edition des propriétés : name, description, champs libres.
Affichage du contenu rich (HTML safe) dans un viewer.
Si images :
Cas 1 : description contient une URL http(s) -> afficher image.
Cas 2 : KML contient des références d’images (ou CDATA) -> extraire URLs si présentes.
Ne pas tenter d’OCR, ne pas embedder des binaires dans v1.
UI/UX
Layout :
Header : nom projet + boutons Import / Export / Save / Settings.
Volet gauche : liste couches + recherche + filtres.
Volet droit : panneau “Propriétés” de la feature sélectionnée (avec preview images).
Thème gruvbox dark vintage : palette, tokens CSS, typographie lisible.
Toasts + barre de statut (import, parsing, sauvegarde).
Backend
Endpoints :
POST /api/datasets/import (reçoit metadata + contenu si small, ou upload multipart).
GET /api/datasets
GET /api/datasets/{id}
PUT /api/features/{id} (update geometry + properties)
POST /api/datasets/{id}/export?format=geojson
Validation Pydantic : structure GeoJSON, taille max, champs autorisés.
Versioning simple : table feature_versions (timestamp, before/after).
Choix techniques (à appliquer)
Carte : privilégier MapLibre GL JS (vector) + possibilité raster, OU Leaflet si plus simple.
KML parsing : parser côté frontend (lib JS) puis envoyer au backend en GeoJSON normalisé.
GeoJSON : édition via libs de dessin (MapLibre + draw) ou (Leaflet + Geoman).
State management : simple (Zustand) ou équivalent.
UI : TailwindCSS + composants (shadcn-like ou headless) pour rapidité.
Livrables attendus par toi (Claude Code)
Arborescence projet complète.
docker-compose.yml + Dockerfiles frontend/backend.
Backend FastAPI prêt : routes, modèles, migrations (alembic) si nécessaire.
Frontend prêt : carte, import, liste, sélection, déplacement point, édition propriétés.
README clair : installation, variables .env, limites connues, roadmap.
Dataset d’exemple (1 KML, 1 GeoJSON) dans /samples/.
Roadmap (après MVP)
Support KMZ, styles KML (icônes, couleurs).
Edition lignes/polygones.
Auth (OIDC / reverse proxy).
Multi-utilisateurs, permissions.
Import de grands datasets (streaming, worker).
Offline tiles / serveur tuiles interne.
Commence par proposer la structure du repo + fichiers Docker + une première version fonctionnelle MVP. Implémente ensuite par incréments : carte -> import GeoJSON -> édition point -> import KML -> persistance -> export.
Brainstorming outils (stack Docker) pour ce projet Carto / rendu carte (frontend)
MapLibre GL JS : rendu vectoriel moderne, performant, style JSON, compatible “vecteur” + raster.
Leaflet : très simple, énorme écosystème, mais moins “GPU”/vecteur natif.
Mapbox Draw / MapLibre Draw ou Leaflet-Geoman : outils d’édition/dessin (drag points, edit).
Import / conversion
togeojson (KML -> GeoJSON, JS) : classique, efficace.
@tmcw/togeojson variantes / ou libs KML parser modernes.
geojson-validation ou validation custom côté backend.
Pour KMZ plus tard : unzip + parsing KML.
UI moderne
Vite + React + TypeScript
TailwindCSS + tokens de thème (gruvbox).
Composants : Radix UI (headless) ou shadcn/ui-like.
State : Zustand (simple, efficace).
Backend & persistance
FastAPI + Pydantic
SQLite (MVP) via SQLModel ou SQLAlchemy
Alembic (migrations si tu veux solide)
Stockage fichiers : volume Docker (/data)
Export & traitement géo
Shapely / pyproj côté backend si besoin d’opérations (simplification, reprojection), mais v1 peut rester “pass-through” en WGS84.
Sinon 100% côté frontend (GeoJSON only) et backend persiste.
Dev / qualité
pytest (backend)
ruff + black (backend)
eslint + prettier (frontend)
OpenAPI auto (FastAPI) pour tester vite.
Docker / déploiement
2 services :
backend (FastAPI + volume /data)
frontend (build Vite puis Nginx)
Option 3 : un Caddy ou Traefik plus tard (pas requis MVP).
Variables .env : URLs des fonds de carte, limites upload, chemins data.
Fonds “satellite / hybride”
Attention : “Google Earth” au sens strict n’est pas un fournisseur de tuiles libre. Pour MVP :
Utiliser des raster tiles (satellite) et vector tiles (OSM vector) via fournisseurs compatibles, configurables.
Prévoir abstraction “BaseLayerProvider” configurable (URL template + attribution + type raster/vector).
“Hybride” = satellite + labels (deux couches superposées).