Définition générale du projet

[camillemonchicourt]

La discussion amorcée sur https://github.com/PnX-SI/GeoNature/issues/176 continue ici avec des précisions à venir sur le fonctionnement du module.

[DonovanMaillard]

Bonjour à tous,

Voici ci-dessous en PDF la première proposition de CCTP pour le développement du module d'imports.

https://ressources.flavia-ape.fr/CCTP_Module_Imports_PropositionV1.pdf

Parmi les difficultés déjà identifiées, et auxquelles je n'ai pas encore trouvé de réponses :

• Sans option, le choix du jeu de données se fait au début de la manipulation : pas de soucis. Mais si on développe l'option 3, le choix ne peut se faire qu'à la fin (étape 6) : il faudra éviter qu'un utilisateur fasse toutes les manipulations pour se rendre compte, à la fin, qu'il n'a accès à aucun jeu de données pour faire son import...

• Actuellement, c'est voulu mais à discuter, on ne peut intégrer que des données ayant une géométrie. Le module n'assure pas de rattachement à une commune sur la base d'un code INSEE par exemple. Ces manipulations là peuvent se faire via la base de données et il n'est pas prévu que le module permette de le faire (à gérer manuellement pour éviter les complications sur le module).

Un point peut surprendre dans le cahier des charges, c'est que seulement à l'étape 4, l'utilisateur peut se voir refuser son import s'il ne comporte pas toutes les informations utiles. Dans le CCTP, ca parait loin, mais à l'usage, l'utilisateur aura uniquement chargé son fichier, et tenté de faire le mapping des champs (en vain, puisqu'il n'a pas certains champs essentiels dans ses données sources).

Je reste, naturellement, dans l'attente de vos retours et idées sur le sujet ! Donovan

[DonovanMaillard]

Retour de Bernard Bal, CEN Haute-savoie :

Bonjour

Ca semble tenir la route...

Il y a cependant d'emblée un point qui me semble à compléter Dans l'étape 45, page 6 "Cas des géométries" Si l'utilisateur peut remplacer la géométrie par des coordonnées (x,y), il faut alors associer à ces coordonnées une précision en m. En effet, si la donnée est à l'origine rattachée à une commune, le passage à un couple de coordonnées (un centroïde par exemple) peut localiser le point très loin de sa position réelle, y compris à l'extérieur du polygone communal tout en donnant l'impression de provenir d'une donnée ponctuelle... Pour que le "lecteur" de la donnée sache qu'il ne doit pas prendre l'information telle que visible, la précision est nécessaire...

D'autres remarques peut-être dans un proche avenir

[camillemonchicourt]

OK cela n'est pas lié au module Import mais aux champs de la Synthèse

[DonovanMaillard]

Points éclaircis avec B.Bal en effet ;)

[DonovanMaillard]

@gildeluermoz posait la question de faire reposer un service essentiel de geonature (récollement au cd_nom notamment) sur un service externe (API taxref fuzzy match).

En complément, j'ai testé l'API qui génère quelques erreurs qui peuvent être très impactantes, comme déjà vu avec Gil il y a quelques temps. Par exemple, Tettigonia cantans (sauterelle) est automatiquement rattachée à une cigale par l'API. On ne pourra pas éviter toutes les erreurs avec un rattachement automatique, mais il faudra trouver un moyen pour gérer ces exceptions avant d'avoir des millions de cigales à haute altitude et en picardie :)

[gildeluermoz]

Le cas cité par Bernard est géré par les nomenclatures SINP. Il s'agit d'un rattachement à un objet géographique et non d'un géoréférencement : http://standards-sinp.mnhn.fr/nomenclature/23-type-dinformation-geographique-16-08-2016/. Avoir dans le détail comment implémenter au mieux ces cas.

[camillemonchicourt]

Voici ma deuxième relecture avec des commentaires dans le PDF joint :

CCTP_Module_Imports_PropositionV1-CM.pdf

[DonovanMaillard]

Pour le cas cité par Gil, si comme chez Flavia par exemple, un champ précise le type de rattachement, alors ce cas est implémenté d'office dans le mapping des chmps et des nomenclatures. Dans la première étape on indique le champs qui correspond à l'informaion, dans le second temps on indique, pour nos modalités sources, les nomenclatures cibles qui correspondent. Dans le cas ou aucun champs correspond (si c'est pour tout le jeu de données)..... là en revanche il faut permettre de choisir la valeur par défaut. A noter dans la révision du cctp! :)

Merci Camille, je jète un oeil, et apporte mes propres modifications à froid la semaine prochaine , j'ai également des modifs à apporter.

• Le rattachement des noms latin au cd_nom à mon sens ne doit pas être une option, cette fonction servira pour la plupart des jeux de données qui passeront par ce module (excel ou qgis), qui n'ont pas cette info (et qui pour cause, est pénible à rechercher quand on a pas d'outils de saisie autre quu'excel...)

[camillemonchicourt]

Pour le rattachement des noms latins à un cdnom, c'est sur que c'est intéressant mais on peut considérer que c'est un point à gérer manuellement avant import. Mais c'est dommage en effet.

[camillemonchicourt]

Après relecture du CCTP, voici une tentative de schématisation du processus (peut-être à mettre au propre et à intégrer au CCTP ?)

Au-delà des commentaires que j'ai fait dans le CCTP hier, une question importante que je me pose est la pertinence de faire des imports partiels dans la Synthèse si certaines données ne sont pas conformes.

Le risque est d'avoir des incohérences entre le nombre de données Source (importé totalement en étape 2) et leurs équivalents dans la Synthèse.

Avec aussi le risque de créer des doublons dans les données source si on souhaite réintégrer dans un second temps les données qui ont posé problème et qui risquent d'être réintégré dans les données source.

A voir aussi si les imports en étape 2, se font obligatoirement dans une nouvelle table, ou si il est permis d'importer les données sources dans une table existante.

[TheoLechemia]

Petite idée comme ça. Le "fuzzy-search" pourrait intervenir en amont de tout le procesus. On donne un fichier à l'appli, qui renvoie une nouveau fichier avec une colonne cd_nom. Le gbif fais déjà un truc comme ça. ça fait une étape de moins dans le procesus déjà bien complexe d'import.

[gildeluermoz]

Je vous donne mon point de vue sur le sujet. Un peu en vrac. Globalement, il me semble peu réaliste de prévoir un module d'import répondant à toutes les situations. Ou alors il faut des centaines de milliers d'euros et une interface lourde.

Il faut ensuite distinguer 2 approches différentes :

• l'objectif est d'insérer qq part dans la base n'importe quelle données qui seront ensuite retravaillées manuellement par l'administrateur. C'est donc un travail préparatoire et le module d'import aide à certaines taches lourdes (matching de taxons, vérification des dates et des coordonnées, listes des observateurs absents de t_roles, rattachement aux nomenclatures et aux métadonnées existantes, etc...)
• L'objectif est d'insérer des données dans la synthèse. La cible est uniquement la synthèse et l'objectif est de faire matcher tous les champs avec ceux de la synthèse (du moins ceux définis comme obligatoires). Il y a donc un import temporaire, tel que, puis matching des champs, puis matching des nomenclatures et de certaines valeurs jusqu'à la construction d'un import dans une table proche de celle de la synthèse puis import en synthèse. On ne conserve que les données sources utilisables en synthèse. Il faut même se demander si on conserve les données ailleurs qu'en synthèse.

A noter que les étapes de matching en interface sont chronophages pour l'utilisateur. Imaginons, dans le schéma de Camille, à l'étape 5 tu ne parviens pas à faire le mapping des nomenclatures et tu souhaites revoir ton fichier source dans calc. Donc recommencer... ou à l'étape 6 tu n'as pas encore créé ton jeux de données, il faut donc le créer dans l'admin GeoNature puis revenir au module d'import et actualiser l'étape 6 (c'est une complexité pour le dev) Il ne faut donc pas perdre les étapes de matching (complexité aussi)

A noter aussi, quid de la validation ?

En pratiquant le sujet dans GN1, je peux témoigner que je reviens souvent au fichier source. Je le prépare, je l'importe, une fois en base je le vérifie avec un petit script php :

• la présence des informations obligatoires
  • pas de valeurs nulles
  • correspondance avec les types attendus
• les taxons,
• les communes ou tombent les données,
• les observateurs absents de t_roles,
• la conformité des métadonnées (id du protocole, du lot, de l'organisme, de la précision, de la source) S'il y a des soucis, je corrige le fichier source dans Calc puis je le réimporte. Quand tout est ok, je travaille en SQL dans la base (bib_noms, cor_nom_liste, cor_taxon_attribut, import dans une table source puis import en synthèse) Mais on pourrait poursuivre en interface au lieu du sql, sachant qu'il y a x cas particuliers à chaque fois et que pour que l'interface prévoit tous les cas... Y'a du boulot !

A noter que le script me fait gagner bcp de temps et que mon fichier source a une structure définie.

[DonovanMaillard]

Merci Gil,

À mon sens on est dans ton cas 2, on importe les données vers la synthese.

Dans ma proposition on importe tout

On crée une table au format source

On fait les mappings

On envoie les données ok dans la synthese (et gardant le format source, ça c'est essentiel pour nous)

On enleve de la table source les données qui n'ont pas pu être intégrées à la synthese (c'est qu'elles ne sont pas conformes sur un point important)

Je reprends le cctp lundi et mettrai en ligne ici une nouvelle mouture

Pour le matching des CD nom c'est un point délicat à gérer en amont mais si pas le choix, il faudra bien qu'on renonce à cette fonctionnalité oui

[gildeluermoz]

Dans ton cas il y a 2 niveaux de mapping.

• Un premier assez simple qui fait matcher les champs de la synthèse avec ceux de la sources + identification des champs spatiaux. Ce mapping devrait prévoir des possibilités de nn (date__min et date_max = un seul et même champ dateobs dans la source / commentaire = concaténation de n champs dans la source)

• Un mapping plus complexe du contenu, ligne à ligne pour chacun des champs où l'intégrité référentielles est obligatoire : utilisateurs, taxons, nomenclatures. + cohérence des locs avec ton territoire.

De mon point de vu, c'est sur ce deuxième niveau de matching que l'outil est utile car les différences entre les données sources candidates à l'intégration et le contenu de la base sont faciles à pointer (par contre complexe à corriger) Si on prend l'exemple des utilisateurs : ça va te pointer les utilisateurs pour lesquels une correspondance existe et ceux où elle n'existe pas. De là, il faut soit modifier la source, soit modifier la destination = ajouter l'utilisateur avec UsersHub parce qu'il est nouveau ou modifier la source parce que l'orthographe d'un utilisateur existant est légèrement différente dans la source (Donovan Maillart au lieu de Donovan Maillard. Et pourtant on sait tous qu'il n'y en a qu'un 😊) Avant de poursuivre, il faudra donc soit ajouter les utilisateurs côté base soit modifier l'orthographe côté source. Idem pour les taxons (et je peux te dire que j'ai des tas d'exemples de taxons mal orthographiés) Idem pour les nomenclatures (avec tous les commentaires et toutes les incohérences possibles et imaginables du genre pour un dénombrement : des valeurs numériques et des > à 50 ou nombreux ou abs ou pls...) Le matching de contenu va tjs nécessiter de modifier/compléter soit la source soit le référentiel en correspondance. Il est donc préférable de pouvoir faire des aller retour entre l'interface d'import et les référentiels et/ou la base, puis de relancer une comparaison. X fois jusqu'à ce tout match ou que tu décides de ne pas retenir ce qui ne match pas. Plutôt que de supprimer des données non intégrables, il serait préférable de les taguer "non conforme" et de les conserver. Il est facile ensuite de n'intégrer que ce qui est conforme. Le processus peut d'ailleurs faire ça autotiquement au fur et à mesure que le matching avance et afficher le nombre de lignes intégrables et non conformes.

Ton fichier source et son image en base que tu veux conserver vont diverger. Je ne vois pas comment faire autrement (sauf à copier l'import brut qq part pour mémoire et/ou réinitialisation) Le travail d'import va progressivement enrichir ta source vers une conformité GN ou occurrence de taxon. Cet enrichissement qui se fait par étape est consolidé en base et tu dois pouvoir y revenir quand tu veux avec l'interface pour compléter/finir ou intégrer les qq données qui étaient restées non conformes lors d'un premier import. D'ailleurs, parfois il sera plus simple ou plus sur ou plus rapide de faire certaines opérations en SQL. Rien ne l'interdit. Tu scriptes en SQL sur ta source importée puis tu relances la comparaison en interface.

Donc je verrais bien en point d'entrée soit un nouveau fichier source, soit choisir une source parmi tous les fichiers déjà importés et plus ou moins 'conformifiés'. En gros reprendre un travail en cours.

Ceci veut dire qu'il faut enregistrer en base une liste des sources importées et pour chacune le mapping des champs retenu (+ les correspondances avec les métadonnées). Le mapping de contenu, lui, est consolidé dans la base soit dans les modifs faites sur la source soit dans les référentiels. L'interface peut donc relancer l'affichage des diff n'importe quand.

Désolé si je reprends pour parti le CDC, je n'ai pas pris le temps de le lire 😎

[DonovanMaillard]

Haha, je m'en doutais !! En effet certains points mais pas tous Sont déjà dans le cctp mais peut être à éclaircir par ailleurs.

Quand je parle de srocher une donnée source, ça veut dire dans mon cas stocker dans le format original (tous les champs classiques + additionnels et le vocabulaire original) en base. Pouvoir revenir à la donnée telle quelle à été fournie.

Prévu également dans le cctp, isoler les données non conformes et pouvoir les retelecharger à la fin de l'importation pour que l'utilisateur puisse revenir dessus.

Un petit casse tête m'attend pour lundi mais merci pour les retours !! :)

[DonovanMaillard]

Petit complément @gildeluermoz :

Concernant les utilisateurs et les cor_role dans la synthèse.... je serais pour ne pas effectuer ce rattachement.

• Donovan Maillard (ou Maillart selon le degré de fatigue) il n'y en a qu'un (même pas d'ailleurs...). Christophe Albert ou Albert Christophe, à l'échelle d'une région ou du pays, on peut en avoir plusieurs, et le rattachement serait hasardeux dans ce cas (il le devient encore plus pour des données mal formatées du style D.Maillard) .

• En plus, ca impose d'avoir un role pour chaque observateur. Typiquement niveau SINP, je vais pas pouvoir gérer ça par exemple. Le but du module c'est aussi et surtout de gérer des données qui proviennent de l'extérieur : partenariats, sciences participatives ou ce genre de choses impliquant des personnes qui ne sont pas de la structure. Donc je ne remplirais même pas cor_role_synthese. A voir pour le faire en option avec une fonction qui se lance après coup pour ceux qui sont intéressés peut être? D'autant que même s'il est question de CRUVED, il n'y a pas d'actions d'Update ou delete sur la synthèse, puisque ca passe par le module producteur, qui n'existe pas ici. A la limite on empêche de suivre le "read" ou "export" de portée 1... des cas à mon avis assez particuliers.

Pour les taxons, en effet c'est un problème qui va être central, couteux, et ..... qui va continuer à nous faire cogiter un petit moment...

[camillemonchicourt]

Oui le champs observers en texte est fait pour ça. Importer les observateurs en texte à plat.

Remplir la cor était dans la cas où le fichier source contenait déjà les id des rôles. Pas pour faire rematcher avec des noms à plat. Mais ouais c'est de trop je pense

[orovellotti]

J’ai pas tout lu mais peut être que je peux vous aider.

On a fait pas mal de modules d’import par le passé.

Il y a trois grandes étapes 1/ fichier : le fichier est il valide 2/ structure : les colonnes sont elle la 3/ données: les données dans les colonnes sont elle valides

Pour l’étape 3, il y a moyen de voir ça comme un système à base de règles génériques qui testent le contenu des colonnes et loggue des erreurs à corriger dans une table de log.

Les erreurs peuvent être bloquante ou pas.

Il faut généralement aussi une table qui stocke les imports (qui/quand/quoi) pour pouvoir revenir dessus.

Bon week-end

[DonovanMaillard]

Bonjour,

Merci @orovellotti . En effet, ces étapes se retrouvent dans notre projet, qui reste à consolider.

Une question se pose sur le stockage des données sources "brutes" (sans aucune transformation de forme) . Doit on les garder, est-ce que ca doit être fait d'office ou est-ce que c'est un paramètre du module ? Est-ce que le stockage du fichier source sur le serveur suffit pour cet archivage au final pas le plus utilisé à priori?

Les données brutes retravaillées, elles, sont forcément stockées (des dates complètes, remises en forme, un cd_nom calculé, le tout stocké avec l'ensemble des champs de la donnée source. Ici on ne garde alors que les données valides.

Les données de synthèse, bien entendu, sont renvoyées dans la synthèse.

Se pose aussi dans notre cas la possibilité ou non d'Uploader des données sur une table préexistente. A la fois très intéressant pour avoir une base de données organisée (1jdd=une table d'import) qui puisse être alimentée sans créer de nouvelles tables à chaque fois (utile aussi pour la gestion des doublons etc). A la fois, avec toutes les complexités que ça apporte : modification de données déjà importées auparavant, gestion des doublons, gestion ou non des données supprimées etc. Des points à affiner, j'en parlerai notamment demain avec @gildeluermoz selon ses dispos, qui pratique les imports depuis quelques années ... Le CCTP sera mis à jour et diffusé dans les jours à venir en conséquences.

[camillemonchicourt]

Les 3 étapes indiquées par @orovellotti sont importantes en effet. Dans notre cas, il faut ajouter un aspect important est le matching des champs et des valeurs de certains champs, car l'enjeu central est de ne pas prédéfinir le format et le contenu des fichiers sources à importer.

[DonovanMaillard]

L'étape 3 de @orovellotti correspond plus ou moins à cette étape justement à mon sens

En fait j'adapterais ces 3 étapes comme cela :

1/ fichier : le fichier est il valide 2/ structure : les colonnes minimales sont elle la 3/ données: les données dans les colonnes sont elles d'un format valide pour permettre les mappings et les mises en correspondances.

[gildeluermoz]

Qq éléments :

1) le fichier est valide

Est-ce que les critères de validations sont définis ? C'est quoi un fichier valide à ce stade ?

Une question se pose sur le stockage des données sources "brutes" (sans aucune transformation de forme) .

Le fichier source comporte parfois de l'hétérogénéité dans le typage (une colonne peut comporter des nombres et des textes alors qu'uniquement des nombres sont attendus). Donc si tu stockes le fichier source brut tel que, dans ce cas, tu ne peux utiliser que le type text.

Doit on les garder, est-ce que ca doit être fait d'office ou est-ce que c'est un paramètre du module ?Est-ce que le stockage du fichier source sur le serveur suffit pour cet archivage au final pas le plus utilisé à priori?

Je dirais qu'il faut le faire dans un schéma dédié (source_import ?) car le stockage en base est plus pérenne. Il permet de centraliser, de sauvegarder et de faire des liens avec l'usage. Le mode fichier est plus fragile et beaucoup plus "format dépendant" (ods, csv, xls, xlsx, shp, json, ....). Les fichiers peuvent aussi se trouver isolés de la base à un moment donné.

Ici on ne garde alors que les données valides.

Je garderais tout avec un champ is_valide pour pouvoir revenir facilement sur ces données non retenues lorsque des compléments d'info arrivent ensuite. Pour 2 raisons :

• cela évite de devoir tout réimporter et refaire les matching.
• comme c'est le même jeux de données et le même fichier source, autant que tout reste ensemble.

Se pose aussi dans notre cas la possibilité ou non d'Uploader des données sur une table préexistente.

C'est précisément la question que je posais dans un précédent commentaire : soit tu importes des sources sans structure prédéfinie à destination de la synthèse, soit tu as une structure préexistente et tu empiles tes sources dans une même table. Le workflow du module n'est alors pas le même est je pense qu'il faut choisir entre ces deux approches fortement structurantes. Personnellement, je mixe les deux. J'ai une structure de fichier source prédéfinie et je pousse les données dans des tables différentes selon les cadres d'acquisition (ensuite tout va dans la synthèse). Mais je fais ça principalement en SQL. Si tu veux le meilleur des 2 mondes, il faut que le module implémente un mécanisme de choix de la table de destination. La structure de cette table de destination est lue et l'interface te propose, à la place d'un matching avec la seule synthèse, un matching avec la table de ton choix. Mais là, c'est plus complexe à faire et surtout, cela rajoute une étape car il faut 2 matching : un avec la table choisie puis un entre la table choisie et la synthèse (tous 2 enregistrables bien sur, pour ne pas avoir à les refaire à chaque fois)...

[DonovanMaillard]

Merci Gil pour ce retour,

"est ce que le fichier est valide, critères etc" : à mon sens à cette étape, on regarde le format (on importe pas un xlsx), et la complétude d'une archive pour le shapefile (j'ai bien le prj le shp le dbf etc).

Donc on partirait dans l'idée de garder la table au format source, tout en text, avec un champs is_valid (qui me va bien).... dans un schéma à part (gn_import ou autre). Ce format est isolé du reste. Il se limite donc à l'équivalent de la fonction import_csv, avec une série de controles et un ajout "is_valid" boolean. A partir de là, on prend toutes les lignes valides sur la base de ce champs nouveau, et on importe les données, qu'on transforme correctement, dans la synthèse. On stocke un identifiant source obligatoirement.

Sur le dernier point, je misais sur les deux également : Dans l'idée, je choisissais pas une table, mais un jdd au début de l'import (et donc, 1jdd = 1 table d'import). Soit mon jdd n'a pas encore d'import associé, c'est mon premier, et dans ce cas je prends le format de la table source et je crée la table dans la bdd. Soit j'ai déjà une table d'import pour ce jdd, et dans ce cas le fichier que j'upload DOIT être conforme au format du premier fichier importé. Ca implique une contrainte, certe, mais c'est pertinent dans le sens ou ça implique 1JDD=1format de données. Si une nouvelle colonne existe, on crée un nouveau jdd. (et à la fois si on veut exporter les données sources d'un jdd, c'est intéressant d'avoir un format homogene dans tout le lot). L'utilisateur, en choisissant son jdd, choisit sans le savoir sa table.

En option, on peut imaginer une correspondance pour que l'administrateur puisse dire "tel id_jdd = tel schema.table" de facon à organiser sa base sans que le schéma gn_import ou source_import dans ton exemple soit un "fourre-tout" (dans mon cas, assez essentiel si je veux m'y retrouver dans 6mois/1an...). On vise pas le meilleur des mondes ou on intègre des données dans toute table possible, mais on crée pas non plus une nouvelle table à chaque import (si quelqu'un fait un import pour alimenter la base tous les mois ou tous les deux mois on s'y retrouvera vite plus...).

Un grand merci @gildeluermoz pour ces 2 points qui m'aident grandement pour finaliser le CCTP.

Petite précision : ce fonctionnement permettra aussi d'associer un mapping à un jdd donné. Donc si en janvier j'importe mes premières données, je crée une table, je fais mes mappings. Si en février je viens abonder le jeu de données, j'importe le même format dans la même table. Mon mapping est globalement prêt (reste à compléter si de nouvelles valeurs apparaissent dans mes champs liés à la nomenclature).

[gildeluermoz]

Quelques principes et points clés :

• pouvoir revenir sur un travail non terminé (par manque de temps ou d'information)
• pouvoir à tout moment switcher entre le mode interface du module et le SQL ou manip dans pg_admin. Sous entendu toutes les actions en interface se traduisent par un enregistrement en base ET toutes les modifs en base peuvent être chargées en interface à tout moment.
• réimporter un même fichier source après correction sans créer de doublons. Il arrive en effet que l'on ait besoin de retourner son fichier au producteur pour compléments/corrections/précisions. Ce besoin peut-être identifié durant le workflow d'import qui sera alors stoppé. Du coup le workflow devra être repris à partir d'un nouveau fichier (le même mais corrigé). Ce qui est important c'est que les données ne soient stockées 2 fois (bouton d'annulation qui efface toutes traces d'un import ?)
• Les mapping sont chronophages et ne doivent pas être à refaire si on importe un nouveau fichier avec la même structure. Enregistrer les mapping en les nommant ?

Proposition technique :

• Découper le workflow en étapes (plus détaillées que les 3 proposées par @orovellotti) bien identifiées dans l'interface avec 3 états (todo, doing, done) enregistrés en base.

A vérifier :

• quid de la validation éventuelle et dans tous les cas du statut de validation des données importées ? Si tous les observateurs des données importées sont en mode texte et que les données correspondantes en synthèse n'ont ni id_role, ni id_module, toutes les données importées n'ont pas de CRUVED observateurs (portée 1). Donc pour les observateurs en questions ayant des droits dans geonature : possible soucis pour la validation, attention au effet de bord lors des exports.

Question : Faut-il identifier "l'importateur" qq part ?

[DonovanMaillard]

Bonjour à tous,

D'abord merci à vous pour les échanges qu'on a eus, et qui ont posé pas mal de questions (@gildeluermoz , tu détiens la palme!)

Un certain nombre de propositions ont été gardées, permettant de produire une nouvelle version du cahier des charges, largement abondée. Elle est disponible ci-dessous et sera diffusée la semaine prochaine auprès des éventuels prestataires.

Télécharger le CCTP ici

Les meilleurs compromis ont été recherchés pour éviter la perte de temps lors des imports, et que les soucis rédhibitoires soient identifiés le plus tôt possible. Malgré tout l'import est complexe et on ne pourra pas d'affranchir de toutes les difficultés!

Merci à tous pour vos retours éventuels, dont nous pourrons tenir compte jusqu'en début de semaine prochaine,

(Gil, pour te répondre : l'id_role qui a fait l'import est conservé dans l'historique de l'import) (seule remarque non gardée pour l'instant, la possibilité de recharger un fichier source à toute étape en y faisant des modifications, dans ce cas précis on doit revenir à zéro (on peut uniquement faire des corrections coté base de données). Mais s'il manque des infos essentielles, on le sait dès le début des mappings, donc avant de faire le gros du travail). Donovan

[DonovanMaillard]

Bonjour,

Suite à la consultation lancée il y a un mois, nous avons reçu une unique proposition technique et financière pour le développement du module d'imports.

Nous analysons l'offre en détail, et vous ferons un retour d'ici lundi/mardi prochain pour préciser si le module pourra être développé et avec quel niveau de complexité par rapport à l'optimal décrit dans le cahier des charges.

A bientôt, Donovan

[camillemonchicourt]

Le CCTP final est consultable ici : https://geonature.fr/documents/cctp/2019-02-CCTP_Module_Import_GeoNature.pdf

Une première réunion de lancement a eu lieu hier avec le prestataire retenu pour préciser les différentes et construire une première maquette fonctionnelle : https://github.com/PnX-SI/gn_module_import/issues/3

[DonovanMaillard]

Le compte-rendu de la réunion de cadre est disponible ici en pdf :

CR cadrage module imports.pdf

En complément des échanges de la réunion, je proposé que le champs gn_is_valid ne soit pas recalculé après la fin de l’étape 4, et que ce soit ce champs qui définisse les données réellement intégrées à la synthèse ou réexportées à l'étape 5. Cela permet éventuellement à l’administrateur, coté base de données, de procéder à ses propres contrôles à cette étape. (Juste avant l’intégration, l’administrateur peut s’assurer que toutes les données sont bien sur son territoire et qu’il n’importe par exemple que les taxons qui lui conviennent, en déclarant les données invalides si elles ne répondent pas à ses attentes par exemple).

Organisation des itérations :

• Itération 1 - Import simple csv
• Itération 4 - Mappings de champs et de contenus
• Historique des imports (noté 5 sur la maquette)
• Itération 5 - Arrêt et reprise d'un import + réactualisations des données
• Itération 2 - Import d'un fichier geojson
• A voir selon les tests : visualisation des regroupements effectués dans les mappings de contenus

[DonovanMaillard]

Un certain nombre de fonctionnalités ont été et seront ajoutés par @TheoLechemia dans le cadre de Ginco et du travail piloté par le MNHN.

Je voudrais savoir s'il est possible de récapituler ici les fonctionnalités nouvelles faites ou attendues, et de redéfinir de manière globale comment ces ajouts seront imbriqués dans le module existant ? (qu'est-ce qui viendrait par défaut, qu'est-ce qui serait mis en conf, qu'est-ce qui est spécifique au projet ginko le cas échéant?). Me concernant je n'arrive pas à avoir une vision d'ensemble et il est difficile de voir, fonctionnalité par fonctionnalité, ce qui se fait.

[camillemonchicourt]

La version 1.0.0 module a été conçue et développée pour un administrateur qui doit intégrer des fichiers de données de forme diverses et les intégrer dans la Synthèse basée sur le standard Occurrences de taxons. Cela peut être un administrateur de données qui va jongler entre l'interface et la BDD, ou bien un administrateur de plateforme GeoNature (SINP ou pas), qui connait les standards SINP et pour qui l'interface du module va lui permettre d'intégrer des données sans devoir manipuler la BDD.

On veut désormais aussi pouvoir proposer l'outil à des utilisateurs qui ne sont pas administrateurs de données, avec un format de fichier source prédéfinie. Cela peut être un chargé de mission, un producteur partenaire, un dépositaire... On a alors un modèle d'import (mapping) prédéfini, non modifiable par l'utilisateur, correspondant au modèle de fichier à importer. L'utilisateur va se baser sur celui-ci mais le module va lui permettre de l'ajuster si certains champs ne correspondent pas.

Cela nécessite de pouvoir définir un mapping de champs et un mapping de contenus par défaut qui sont chargés automatiquement par défaut et partagés entre tous les utilisateurs (#98). Il faut aussi mettre en place un CRUVED plus fin pour définir qui peut modifier ou créer un mapping.

Pour ces utilisateurs, ils sont censés utiliser un format de fichier prédéfini correspondant au mapping par défaut. Il est donc souhaitable de pouvoir alléger et simplifier les interfaces et les différentes étapes. Le mapping par défaut leur est chargé par défaut et pour commencer, ils ne peuvent pas le modifier ni en créer un autre. Par défaut l'interface de mapping ne leur affiche que les champs qui n'ont pas été mappés automatiquement, en leur permettant de les ajuster si leur fichier source diffère du mapping par défaut. Il est aussi désormais prévu de pouvoir masquer complètement l'étape de Mapping des contenus sur le principe qu'ils ont utilisés les nomenclatures attendus par l'import (#100).

En plus de cela, une révision globale du code et des performances est en cours. Les contrôles sont aussi revus et complétés.

RÉALISÉS :

• Supprimer un import (et les données associées) (#124)
• Ajout de la possibilité de ne pas afficher l'étape "Mapping des contenus" en définissant un mapping par défaut (avec les paramètres ALLOW_VALUE_MAPPING et DEFAULT_MAPPING_ID) (#100)
• Liste des imports : Ajout d'une recherche libre et du tri des colonnes (#75)
• Liste des imports : Ajout de la colonne "Auteur" (paramétrable comme les autres colonnes) #92
• Liste des imports : Ajout d'un lien vers la fiche du JDD correspondant
• Séparateur des fichiers CSV importés détectés automatiquement (#119)
• Documentation de l'utilisation et du fonctionnement du module

EN COURS :

• Import possible des données sans géométrie en utilisant les colonnes codecommune, codemaille ou codedepartement et en récupérant id_area et leur géométrie correspondantes dans la couche des zonages du ref_geo (#107)

• Révision et complément des contrôles des données et amélioration des rapports d'erreurs (#114)

  • Ajout d'un tableau d'erreur à la première étape d'upload du fichier
  • Ajout d'un rapport d'erreur consultable à la dernière étape avant intégration des données et depuis la liste des imports
  • Ajout de contrôles, sur les géométries notamment
  • Enregistrement et affichage des lignes en erreur
  • Ajout d'une vue gn_imports.v_imports_errors permettant de lister les erreurs d'un import
  • Ajout du paramètre FILL_MISSING_NOMENCLATURE_WITH_DEFAULT_VALUE pour remplir ou non les nomenclatures en erreur par la valeur par défaut définie dans la BDD

A SUIVRE :

• Fluidification des étapes de mapping des champs et des contenus (#113)
• Implémentation du CRUVED pour identifier si l'utilisateur peut modifier ou créer un mapping
• Paralléliser les traitements et les contrôles (#123)
• Renommage des intitules (#122)
• Factorisation et corrections diverses

[camillemonchicourt]

Avec les versions 1.0.0 et 1.1.0, on a maintenant une bonne base de module fonctionnelle.