Import vers Monitoring, Occhab, Occtax...

[Adrien-Pajot]

Bonjour,

Ne me souvenant jamais si cela a déjà été discuté/si c'est dans les cartons, j'ouvre une discussion :
la possibilité d'utiliser le module d'import vers le module monitoring est-elle envisager ?
Celle-ci est en tout cas espérée mais implique beaucoup de réflexions....

[DonovanMaillard]

Pour le moment ce n'est pas sur le tapis et ce n'est pas si simple techniquement, d'autant plus pour le module monitoring dont les infos attendues dans les champs json sont variables.

A l'heure actuelle les réflexions et travaux se concentrent sur l'amélioration de l'existant et sa robustesse pour traiter au mieux et de manière plus performante les imports vers la synthese. Un import vers occtax serait également un besoin pour certains et moins complexe car on connaît les formats attendus mais ca reste compliqué.

En l'état. Le module a des prémices pour supporter différentes cibles (dict fields etc qui ne sont pas en dur). Mais bcp de choses restent quand même à consolider avant d'envisager plusieurs cibles.

Se pose aussi la question de la pertinence. Les modules de saisie ont leur propre schéma destiné à recueillir les donnees qui y sont saisies. La synthese a vocation à synthétiser les donnees venant de plusieurs sources. Ca mérite réflexion je oense au niveau concept...

[camillemonchicourt]

On discute et réfléchit au sujet de loin depuis un moment car le fait de pouvoir importer dans Monitoring et dans Occhab, voire dans Occtax, est souvent évoqué.
Et il est prévu de travailler sur l'import vers Occhab cette année.

Pour cela on a imaginé 3 possibilités techniques :

• Créer un module de A à Z pour chaque import dans une destination différente, quitte à dupliquer pas mal de code entre chaque module d'import dans une destination différente
• Factoriser une partie socle du module d'Import en tant que sous-module commun, pour tout ce qui concerne l'upload d'import, les traitements en asynchrone, les composants frontend génériques, le lancement des contrôles. Et ensuite un module par destination pour leur partie spécifique à la destination (import final, contrôles des données...)
• N'avoir qu'un seul module, mais en séparant bien dans le code la partie générique et commune évoquée dans le scénario 2 et les parties spécifiques à chaque destination

C'est plutôt le scénario 3 qui nous semble le plus pertinent et le plus adapté pour éviter la multiplication des modules à installer et maintenir et pour n'avoir qu'une seule entrée où on commence par choisir sa destination.

Mais à analyser plus précisément techniquement comment on peut découper tout ça et si c'est viable techniquement.
Dans le refactoring en cours, @bouttier a commencé à faire en sorte que les contrôles liés à une destination soient mieux séparés et regroupés comme un module.
Mais il faudrait aller plus loin dans le découpage pour pouvoir alimenter plusieurs destinations.

Autre élément pas anodin est qu'actuellement on importe dans la Synthèse qui est une table à plat avec un fichier à plat.
Si on veut importer dans Occhab, on devra alimenter plusieurs tables (une des stations, une des habitats), à voir si on fait ça avec un fichier où les 2 niveaux sont remis à plat ou si on importe 2 fichiers.
Pour Monitoring, la destinations a plusieurs tables avec plusieurs niveaux (sites, visites, observations) mais s'ajoute à cela que l'on peut vouloir importer des données qui doivent être associés à des sites existants.

[camillemonchicourt]

La réflexion sur une V3 du module IMPORT qui permettrait d'alimenter d'autres destinations que le module SYNTHÈSE a bien avancé :

• Après analyse technique, il a été retenu que le module IMPORT pouvait évoluer pour alimenter d'autres destinations, plutôt que de développer un outil d'import spécifique à chaque module de destination
• @bouttier a fait une analyse et proposition technique qui a un peu évolué depuis : multidest.pdf
• Les premiers développements ont commencé dans cette PR - Support import to multiple destination #495

Le principe général est de :

• Rendre plus générique le module pour pouvoir spécifier plusieurs destinations
• Factoriser les fonctions, interfaces et contrôles qui peuvent être communs à toutes les destinations
• Que chaque module de destination vienne renseigner et définir ses champs, ses spécificités, etc... pour que le module Import n'ait pas à gérer ça, ni à connaitre les destinations, qui peuvent être des modules non installés ou spécifiques à certaines instances
• D'intégrer le module Import dans le cœur de GeoNature car il s'agit d'une fonction transversale et maintenant qu'il est robuste et largement utilisé, pour en faire une brique du cœur de GeoNature que chaque module peut utiliser et étendre.

Niveau interface, on gardera les principes et fonctionnalités actuelles, en les étendant à plusieurs destinations :

• On arrive sur une liste de tous les imports. On peut filtrer les imports par destination
• Quand on veut créer un nouvel import, on pourra sélectionner la destination (selon les permissions de l'utilisateur connecté). Si j'ai des permissions C dans le module de destination et des permissions C dans le module Import, alors je peux créer un import vers le module de destination.
• Les JDD, les formulaires de mapping et les modèles de mappings dépendent des permissions de l'utilisateur et du module de destination
• Depuis un module de destination, je peux avoir un accès direct aux imports dans ce module, avec un bouton IMPORTER si j'ai des permissions sur le module IMPORT et de création sur le module de destination. Cela me renvoie alors directement au module d'import avec le module de destination déjà sélectionné
• Il faudra désormais pouvoir importer vers des modules composés de plusieurs tables dans les modules Occtax, Occhab, Monitoring (contrairement à la Synthèse qui est à plat). Il est proposé de faire des imports dans les différentes tables du module depuis des fichiers à plat, pour simplifier l'utilisation et la préparation des fichiers à importer.
  • Ainsi si je veux importer 2 stations d'habitat qui ont 3 habitats chacunes, alors j'importerai un fichier qui a 6 lignes, où les infos des 2 stations sont dupliquées
  • Si j'importe des habitats sur une station existante, alors je renseigne son UUID dans le fichier à importer et dans ce cas-là la station ne sera pas créé, mais on créera uniquement des habitats associés à cette station. Cela pourra permettre à terme d'avoir un fonctionnement similaire pour importer des observations vers la Synthèse associés à plusieurs JDD, en mentionnant leur UUID dans le fichier à importer (Pouvoir avoir plusieurs jeux de données destinataires dans un import #493)

Les développements vont commencer par permettre d'importer dans Occhab, puis Monitoring (plus complexe car plus de niveaux et surtout car la structure des sous-modules est différente à chaque sous-module).
On pourra ensuite envisager des évolutions pour importer vers Occtax, Métadonnées, ou d'autres modules plus spécifiques.

[gildeluermoz]

Pour importer vers occtax est-ce qu'une première approche consistant à pousser des données de la synthèse vers occtax ne serait pas plus générique et plus simple que de complexifier le module d'import ? Synthèse et Occtax sont très proches. Synthèse étant presque une vue applatie des 3 tables d'Occtax.

Dans le module d'import, l'utilisateur choisi un import terminé et il clique sur un bouton 'vers occtax'. Il faut "juste" désactiver les trigger qui renvoient occtax vers la synthese avant d'écrire dans occtax et gestionner les UUID.

Sinon à voir s'il serait pertinent que ça trouve une place dans le module metadonnées pour s'appliquer potentiellement à d'autres source qu'Import. Dans la gestion des jdd par ex. (ceux qui contiennent déjà des données). En analysant au préalable les effets de bords biensûr.
Bon, faut bien gérer les données qui sont déjà dans occtax ainsi que les uuid mais c'est une piste pour enrichir GN d'une fonctionnalité certainement utile dans le cas de migration d'un autre outil vers GN.

Pour insérer vers Monitoring, c'est une autre affaire me semble t-il. Ca demande une grosse préparation des données à importer, avec la préparation de couches pour les sites, et toutes les spécificités et cas particuliers de chacun des sous-modules...

[camillemonchicourt]

On va faire évoluer le module d'IMPORT pour qu'il puisse alimenter Occhab, potentiellement aussi Occtax qui sera assez similaire.
Monitoring sera plus complexe mais est prévu.
Je préfère rester dans les modes de fonctionnement classique des imports, plutôt que de faire quelque chose d'un peu complexe et spécifique qui alimenterait la Synthèse et permettrait d'aller dans l'autre sens vers Occtax.

[camillemonchicourt]

En complément, le support de présentation du COTECH du 19 décembre de présentation faite par @bouttier :
import-multidest.pdf

[marie-laure-cen]

Pour occtax si besoin je peux transmettre mon code pour:

• créer via python les 3 tables relevés / occurrences / dénombrements dans gn_imports depuis une table d'observation (j'ai utilisé jupyter notebook avec installation autant que faire se peut des dernières versions de sql alchemy, pandas... donc ça peut ne pas être utile si trop de différences de version avec GN?)
• importer ces éléments dans pr_occtax via des requêtes sql en remplissant au passage les tables cor_... et récupérer les id_releves_occtax et cie pour les niveaux suivants