Closed CharlesGaydon closed 8 months ago
J'ouvre une branche exploratoire pour regarder un peu l'architecture des fichiers de store-ref.
Pour préciser, l'ortho d'un département correspond aux dalles entières couvrant le département bufferisé.
Après différentes discussion et inspection de codes de création de patches à partir des ortho de store-ref, ma réflexion sur l'approche "catalogue" évolue, et j'identifie une étape intermédiaire qui semble incontournable.
En s'arrêtant à des fichiers JPEG2000 disjoints, on a la problématique non-négligeable des patches à la frontière entre deux dalles (1km x 1km ou plus larges). Le passage vers un VRT puis vers un fichier COG par millésime (département x année) est nécessaire. C'est l'approche adoptée pour la création des jeux de données OCS.
Une bonne nouvelle : une initiative avait été lancée dans ce sens à l'été 2022 : "calcul France entière (en fait pas tout à fait, il manque les départements 9x et les DOM) l'été dernier.", "les données sont sur le store-REF (\store\store-REF) dans produits/ortho-images/Ortho/COG75", "OrthoHR".
Il manque les orthos 2022. Et ca ne concerne que le RGB. Au lieu de faire mon bricolage JPEG->COG de mon côté, je me rapproche des personnes à la manoeuve, pour voir si on peut reprendre leur méthode, l'étendre à l'infrarouge, et s'assurer que le tout est à jour.
Et parallèle : je développe bien un extracteur bd_ortho_millesime
, mais basé sur du ~COG~.
Je vais repartir d'une nouvelle branche pacasam propre pour cela. :)
Après différents échanges, je repère ceci : la création du COG prend un temps important (24h/millésime d'après ce que j'ai entendu). Travailler directement depuis un VRT paraît à court terme une meilleure approche.
Je vais développer l'extracteur dans ce sens, et créer les VRTs suffisants pour le jeu de données forêt.
Branche 52-bd_ortho_vintage_from_vrts Cf. la PR pour les todos
Situation actuelle On utilise le geoportail pour coloriser les patches de Lidar. On risque (et on déjà) d'avoir des orthoimages de moins en moins synchrones avec le Lidar. Ca n'a pas un impact critique actuellement - la données ortho est de toute façon désynchronisées - mais ça en aura de plus en plus au fil des mises à jour. Et conceptuellement ce n'est pas hyper solide.
Surtout, pour la création de notre jeu de données "classification d'espèces forestières pures", a.k.a. "PureForestID dataset", ça nous pose problème. En effet, il y a déjà 8 département mis à jour dans la BD Ortho, dont les images ne correspondent donc plus à celles utilisées pour l'annotation de la donnée. On aurait besoin d'un plus fort contrôle sur la données utilisée.
Proposition
Pour moi on peut distinguer les sujets "PureForestID" et "jeux de données d'apprentissage issus de Lipac" , et se concentrer d'abord sur le premier uniquement, pour éviter de tout casser notre système de création de jeux de données. Logique d'extension, en modifiant peu l'existant : on ne change pas la logique de création des jeux d'entraînement pour l'instant = on ne modifie pas
laz
.orthoimages
enbd_ortho_today
: c'est un extracteur à date. Logique de : "Il existe, autant le garder en étant clair sur son usage".Créer un extracteur
bd_ortho_vintage
(vintage = millésime). C'est un extracteur qui a besoin depatch_id
,geometry
,split
,target_year
. Il crée un jeu de données de patches RGB+NIR en visant la données la plus proche detarget_year
.target_year
.Cas limite : aux frontières des départements, dans la BD Ortho diffusée par flux, il y a bufferisation à 100m autour d'un département. Je ne sais pas encore quelles conséquences ça peut avoir quand on part de données annotées mais je pose ça là.
Et si ça marche Si ça fonctionne bien, on peut imaginer que la colorisation des laz se fait toujours dans un second temps, après la création de deux jeux de données : un de laz et un de geotiff. C'est du pdal pur, d'autant plus aisé si les noms des patches extraits sont les même. Et pour LiPaC, il faudra simplement identifier pour chaque bloc la target year. Ca peut se faire à la main rapidement.