panelVisibleTab() renvoie null tant que la fiche détaillée est ouverte,
quel que soit ce qui redéclenche panelRender (grip, redimensionnement,
changement phoneQuery…) : le cadre d'export ne rouvre plus derrière elle.
Rétablir l'onglet Export après un retour (restoreTabAfterDetails / M5)
repose désormais le cadre sans recadrer la vue ni le recentrer
(nouveau drapeau RESTORING_TAB, distingué d'une ouverture explicite par
l'utilisateur). BOOTSTRAPPING est aussi réarmé quand /api/map/meta échoue,
pour qu'une ouverture explicite ultérieure de l'onglet recadre bien la vue.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Retour/Échap depuis la fiche détaillée ne retouche plus la hauteur du volet
téléphone (openTab remplacé par un rétablissement direct de l'onglet) ; le
fond OSM suit le thème sauf choix explicite (migration du localStorage et des
défauts serveur en v3, plus de dark:true hérité de l'ex-webapp) et part du
bon thème dès sa création (plus de flash sombre) ; l'onglet Export mémorisé ne
recadre plus la vue au premier rendu (lien partagé préservé) et referme son
cadre pendant que la fiche détaillée est ouverte ; la qualité affichée suit le
nom réel de la dalle rendue ; un second clic referme la fiche au lieu de
déplacer son contour derrière elle ; couleurs en dur restantes tokenisées
(--tile-sel, --gps, .gen-log) et lisibles en thème clair ; localStorage
corrompu (lidar-panel, lidar-print) n'y casse plus l'interface.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
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>
Un clic sélectionne toujours la dalle sous le curseur (cadre sur la carte),
générée ou non : emprise, rendu et recalage des passes s'affichent tout de
suite ; la fiche IGN (date et heure du scan LiDAR, capteurs, mission,
édition, nombre de points, lien de téléchargement du .copc.laz) arrive à
part via /api/map/ign, mise en cache, sans jamais bloquer la sélection.
Une rose des vents donne la couleur de chaque orientation de pente du
relief orienté, avec la même formule CIELAB que le rendu.
La génération impose la classification IGN (sol) et le raccord de 100 m
avec les dalles voisines : plus de réglage dans la carte, défauts CLI
alignés.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
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>
Nouvelle visualisation relief_oriente : une image RGB unique qui fusionne
l'openness positive locale (MNT détendancé σ 10 m, rayons 5/10/20 m,
16 directions) portée par la clarté CIELAB et l'orientation des pentes
portée par la teinte. Échelle log fixe et support de 40 m sous la bande
de raccord de 100 m : dalles jointives. Calcul sur grille décimée à 0,8 m,
noyau dédié (CuPy RawKernel, numba parallèle, repli numpy) et colorisation
par table L* × teinte : ~8 s par dalle sur CPU au lieu de ~50 s.
L'openness positive et négative est normalisée par des références figées
mesurées sur 15 dalles au lieu d'un z-score par dalle, qui rendait
l'échelle de couleur non jointive.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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.
La maintenance de fond plafonne a LIDAR_TILE_BACKGROUND_MAX_Z (16 par
defaut) : les zooms natifs 17-18 de l'interface restaient transparents
sur une machine en cache seule. Une tuile absente du cache est
desormais rapatriee de LIDAR_MAPS_URL (quelques dizaines de Ko, mise en
cache, dedupliquee par verrou) sans aucun rendu local sur le chemin des
requetes.
Les boutons dans la barre d'icônes du coin bas droit restaient
introuvables : ils forment maintenant une barre horizontale accentuée
en haut à droite (＋ Zone, ⤒ Compléter), la carte Génération s'ouvrant
juste en dessous.
« ＋ » et « ⤒ » seuls dans la barre latérale droite n'étaient pas
identifiables comme l'entrée de génération : les boutons portent
maintenant leur texte (＋ Zone, ⤒ Compléter) en pleine largeur de la
barre, couleur accent.
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).
Une zone réelle (849 dalles, 3 couches, z5-16) produit ~38 000 tuiles : le
plafond précédent (4096) abandonnait silencieusement le reste, et les scans
suivants ne le reprenait pas (dalles inchangées = rien en file). Une entrée
ne coûtant que quelques octets, la file tient toute la pyramide.
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.
