Commit Graph

12 Commits

Author SHA1 Message Date
3d415de86c Générer d'avance toute la pyramide jusqu'au natif, plafonner la carte au zoom 19 et reprendre les dalles refusées par la file pleine
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-27 13:00:49 +02:00
453530ec3a Synchroniser l'animation de zoom du fond et du relief, dater les tuiles à l'horloge précise
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-27 11:52:13 +02:00
147a469ddc Rendre la carte autonome, télécharger la pyramide en fond, refermer les trous de zoom et borner les workers GPU par la VRAM
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-27 11:23:51 +02:00
934e2dab55 Borner la mémoire de la carte (OOM du Pi) et rallumer le relief orienté par défaut
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-27 10:50:03 +02:00
93317dadd0 Garder localement les sources des dalles sur une carte alimentée par l'amont
Avec LIDAR_SOURCE_URL (Pi), la maintenance rapatrie et conserve les sources
de chaque dalle dès qu'elle apparaît, sans attendre de visite : les niveaux
rendus à la volée restent disponibles quand le conteneur de rendu est
éteint. Seuls les paliers utiles sont pris (vignettes, quadrants 500 m ; la
dalle entière, doublon de ses quadrants, ne l'est pas) ; une source manquée
pendant que l'amont était éteint est reprise au scan suivant.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-27 02:34:12 +02:00
434b7f12fd Mettre à jour la pyramide pendant le rendu et réduire son stockage
Le pipeline régénère l'inventaire après chaque dalle par défaut (tous
lanceurs, sauf --no-index), avec une passe différée quand l'anti-rebond
ignore une dalle. La carte surveille l'inventaire toutes les 10 s et place
les tuiles des dalles modifiées en tête de file de maintenance : la
pyramide suit le rendu au lieu d'attendre la fin du lot.

Stockage réduit pour le Raspberry Pi : seuls les niveaux standard pairs
jusqu'à z16 sont écrits sur disque, en AVIF ; les autres, dont le niveau
le plus fin (~75 % de la pyramide), sont rendus à la volée avec un cache
mémoire, y compris en mode cache seule. L'interface ne demande que les
niveaux pairs et réduit ceux du niveau supérieur aux zooms impairs.
Mesuré sur 8 dalles : ~24 Mo de pyramide avant, 1,2 Mo après.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-27 02:31:11 +02:00
d32502b74e Recaler les lignes de balayage des passes et accélérer le rendu
Troisième passe du calage vertical : chaque ligne de balayage (décalage et
inclinaison due au roulis) est recalée contre le consensus des autres
faisceaux, à toutes les échelles, avec un profil d'étalonnage par faisceau
et par degré d'angle qui retire les écarts non linéaires en travers de la
fauchée. Les lignes sans recouvrement sont corrigées contre leur propre
faisceau. Efface les lignes en creux et la marche au bord de fauchée
mesurées sur LHD_FXX_0999_6882 (validé sur des blocs jamais vus). Calcul
vectorisé, CuPy si GPU ; la gigue par fenêtres de temps devient inutile
quand scan_angle existe.

Rendu plus rapide : encodage AVIF speed 9 (0,6 s au lieu de 4 s par dalle),
classification IGN par extraction directe laspy au lieu de PDAL (4,9 s au
lieu de 13,5 s), comblement des trous et gradients sur GPU, cache numba
persistant dans l'image.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-27 01:57:04 +02:00
31645a42e8 Faire du relief orienté la seule couche produite et affichée
PANEL_VIZ ne contient plus que relief_oriente et pilote désormais tout :
le pipeline sans --only ne produit que cette couche, la génération lancée
depuis la carte aussi, et la carte ne liste ni ne sert en tuiles (panneau,
XYZ, TileJSON, WMTS, JOSM) les autres visualisations présentes sur disque.
Les autres visualisations restent calculables explicitement avec --only.

Corrige au passage _panel_viz_steps, qui ne retenait que les couches dont
le nom de fichier diffère du nom d'étape : la génération depuis la carte
ne produisait que l'openness positive.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-27 00:10:08 +02:00
2a84b76d33 Invalider un marqueur de tuile vide des que des sources plus recentes apparaissent
Une tuile rendue transparente (aucune donnee a l'epoque) gardait son
marqueur .empty pour toujours : naviguer une zone avant de la generer
la laissait vide a jamais en mode cache seule. Le marqueur suit
desormais la meme regle de fraicheur que la tuile — plus vieux qu'une
source (dalle apparue depuis, version amont plus neuve), il est
retire : la tuile redevient en attente, rapatriee de l'amont ou
rendue par la maintenance.
2026-09-26 11:00:31 +02:00
0a2ccee958 Porter la génération de tuiles dans lidar-maps et retirer l'ancienne webapp
La carte à tuiles XYZ devient la seule interface : l'API de génération
(preview, generate, status, stop, file, cell), le job unique + file
persistante, la délégation LIDAR_GENERATION_URL et les garde-fous
(token, LIDAR_REGEN_CIDR) passent de webapp.py à mapserve.py ; l'interface
gagne les boutons + Zone / ⤒ Compléter / régénération à la dalle, les
options de run et la progression cadre par cadre. mapserve sert aussi
l'inventaire /api/tiles et les dalles en statique versionné : le worker
image complète remplace la webapp sur le 8973 du générateur, le Pi
n'exécute plus que lidar-maps. index.py se réduit aux registres partagés
+ vignettes/sous-tuiles/inventaire (l'UI HTML/JS et les mosaïques
d'overview partent avec export.py et les compose/scripts de la webapp).
2026-09-23 23:21:05 +02:00
900332cdbc lidar-maps : navigation en cache seule et pyramide entretenue en tâche de fond
Sur une petite machine (Raspberry Pi), LIDAR_TILE_CACHE_ONLY sert les tuiles
depuis le cache uniquement (tuile absente = transparente non mémorisable,
X-Tile-Pending) et LIDAR_TILE_BACKGROUND fait surveiller les dalles par un
sondeur : chaque dalle nouvelle ou régénérée par le worker remet sa pyramide
en file, rendue à basse priorité et au ralenti. Scan et état pilotables via
/api/map/background, pré-calcul exhaustif toujours via /api/map/warm.
2026-09-23 19:05:58 +02:00
053eb2f529 Ajouter une carte à tuiles XYZ (image lidar-maps) réutilisable dans OSM
L'ancienne carte n'est pas une carte à tuiles : une div Leaflet par dalle,
rotée en CSS pour coller la grille Lambert 93 sur le Web Mercator, trois
paliers d'images choisis à la main, un plafond d'images pleine résolution et
une mosaïque d'overview pour boucher les trous au dézoom. Des centaines de
nœuds DOM, des AVIF de 2500² à 5000² décodés dans le navigateur, un LOD
maison — et rien de réutilisable hors de cette page.

Nouvelle image légère (Pillow + pyproj, ni GDAL ni PDAL, port 8975) servant
une pyramide XYZ EPSG:3857 au schéma OpenStreetMap, rendue à la demande
depuis les dalles et mise en cache dans output/index_xyz/ :

- tiles.py : grille XYZ, reprojection par transformation projective dalle par
  dalle (calage mesuré < 1 px), choix du palier source parmi ceux que le
  pipeline produit déjà (vignette, intermédiaire, quadrant, dalle), cache
  périmé dès qu'une dalle contributrice est plus récente, marqueur .empty
  pour les zones sans donnée, cache d'images sources à budget mémoire ;
- mapserve.py : /tiles/{couche}/{z}/{x}/{y}.png (256 px canonique) et
  @2x.webp (512 px, interface), TileJSON, WMTS, josm.imagery.xml, CORS —
  les rendus deviennent un fond d'imagerie pour JOSM, iD, QGIS, uMap ;
- mapui.py : une L.tileLayer par couche dans un pane isolé — LOD, cache et
  animation natifs de Leaflet ; pile réordonnable (glisser avec barre
  d'insertion, ou boutons ▲▼ au doigt), modes de fusion CSS par couche,
  configuration figeable comme défaut de tous les navigateurs.

Deux amonts pour les déploiements en deux machines : LIDAR_SOURCE_URL
(webapp du pipeline — inventaire complet, dalles rapatriées à la demande) et
LIDAR_MAPS_URL (autre instance carte). Charge bornée et réglable, taillée
par défaut pour une petite machine : 2 rendus et 2 téléchargements
simultanés, 192 Mo de cache de sources.

Mesuré sur 849 dalles réelles : première tuile d'une zone 0,9–3,2 s
(téléchargement compris), ~1 ms ensuite ; un chemin OSM se superpose
exactement à la trace du rendu de pente, et les coutures entre tuiles
restent sous le bruit naturel du terrain.

L'interface historique (port 8973) n'est pas touchée : génération et export
y restent, les deux cartes coexistent.
2026-09-23 14:47:38 +02:00