Gérer différents types de maille

[jpm-cbna]

Dans les imports récents effectués dans le module SFT de Flore Sentinelle, il y a des sites qui utilisent des mailles de 100m ou 250m.

Or, l'interface du module ne sait gérer qu'un seul type de maille qui par défaut ont une dimension de 25m. C'est le paramètre id_type_maille du fichier de config config/conf_gn_module.toml qui le spécifie.

Les scripts d'intégration (voir le dossier bin/) associent toutes les mailles ajoutées au type par défaut renseigné dans le paramètre meshes_code du fichier bin/config/settings.default.ini. Du coup, des mailles de différentes tailles sont associés a un type de maille erroné dans la table ref_geo.l_areas.

Afin, d'éviter l'association a un type de maille défini par un fichier de configuration, nous avons fait évoluer les scripts d'intégration. Voir la doc concernant l'intégration de données sur la branche develop. Mais ce n'est pas suffisant car l'interface du module fonctionne seulement avec un seul type de maille possible.

À faire :

• A priori, le type de maille à utiliser dépend du taxon étudié ou du site (?) => à confirmer !
• Il faudrait donc envisager de pouvoir ajouter le type de maille utilisé dans une table associant taxon (cd_nom) et type de maille ou alors envisagé d'indiquer cette information par site en l'ajoutant à la table pr_monitoring_flora_territory.t_infos_sites.
• Corriger les scripts d'intégrations pour que le type de maille ne soit plus dépendant d'un paramètre de config mais soit directement récupéré des données importées.
• Supprimer la gestion du paramètre indiquant le type de maille dans les fichiers de config. L'information doit être récupérable directement en base de données.
• Modifier l'interface pour afficher le type de maille utilisé sur chaque site.

[jpm-cbna]

En profiter pour ajouter un script de nettoyage des mailles inutilisées pour les types M25m, M100m et M250m.

Les modifications des contours des sites peuvent rendre inutiles certaines mailles ajoutées initialement.

Il est intéressant de pouvoir les supprimer pour éviter d'augmenter le nombre d'intersection inutiles à réaliser à chaque ajout de sites ou d'observations dans la base.