226 lines
6.7 KiB
Markdown
226 lines
6.7 KiB
Markdown
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). |