Mieux contrôler les versions d'orthoimages en partant des GeoTIFF du store-ref
CharlesGaydon opened this issue · 5 comments
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.
- Renommer
orthoimagesenbd_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.
- On aurait besoin d'un mapping à jour qui liste les chemins vers tous les fichiers JPEG2 des orthoimage (RVB et IR) + leur géométrie + leur année. Ca serait suffisant de faire ça sur les années > 2019 j'imagine (à vérifier). Ca doit pouvoir se faire via un notebook.
- A partir de là, on peut croiser géographiquement chaque patch d'un sampling avec ce fichier, et ne conserver que les lignes correspondant à la date la plus proche de
target_year. - Puis extraire pour chaque vignette les patches de geotiff correspondants.
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.
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