Limiter les imports à une liste de taxons définie au JDD

[DonovanMaillard]

Depuis la version 1.2, le module d'import comporte un paramètre qui permet de limiter les imports à une liste de taxons.

Les jeux de données permettent depuis quelques version de se limiter à une liste de taxons, définie au niveau du JDD dans le module MTD.

Il serait pertinent de simplifier ce fonctionnement et supprimer le paramètre spécifique au module d'import, en faisant en sorte que le module n'importe dans un JDD que les taxons qui sont associés à la liste définie pour le jdd en question.

[camillemonchicourt]

Je sais pas.
Je suis pas certain que ça soit une bonne chose de galérer à devoir gérer et mettre à jour une liste de taxons dans TaxHub, par exemple pour tout un rang ou un groupe.
A tenir à jour à chaque mise à jour de Taxref avec les nouveaux taxons, etc...

Pas convaincu et lourd de maintenir de telles listes.

[bouttier]

En quoi maintenir un liste dans TaxHub est plus lourd que maintenir une liste dans la config du module d’import ? C’est kiff-kiff non (avec en plus la config du module d’import pouvant être obsolète sans s’en rendre compte contrairement à une liste lors d’une màj de taxref) ?

[camillemonchicourt]

Ah OK je viens de matter le paramètre ID_LIST_TAXA_RESTRICTION et il faut lui spécifier une liste... OK, je pensais qu'on lui passais un RANG TAXONOMIQUE ou un GROUPE_INPN...
Du coup en effet, c'est la même galère de devoir gérer une liste de taxons dans tous les cas.

Donc je pense que ce serait bien plus simple de pouvoir définir un RANG TAXONOMIQUE ou un GROUPE_INPN et non pas un liste de taxons...

[DonovanMaillard]

Non, un rang taxonomique est bien plus limitant vu la taxonomie et la structure du taxref. Par exemple, pour trouver "invertébrés" :) Mais c'est également le cas pour les papillons de jour (pas de rang taxo), les espèces d'un PNA etc

Les listes existent, sont utilisées au niveau des JDD, il est donc simplement question de supprimer ce paramètre pour utiliser à la place les listes déjà en place du coté des metadonnées.

C'est aussi un soucis de cohérence. Si tu définis qu'un JDD peut comporter une liste de taxons en particulier, il faut que tous les modules et terminaux s'y tiennent , au niveau de la saisie, des imports, des applis mobile etc... si c'est pleinement fonctionnel, ça vaut le coup de maintenir des listes.

[camillemonchicourt]

Bon courage pour gérer et maintenir une liste de tous les taxons correspondant aux invertébrés...
Pour moi, c'est un non-sens au regard de la logique de la taxonomie.

[DonovanMaillard]

C'est pourtant ce que je fais pour le pôle invertébrés :) à chaque MAJ du taxref, je remet dans la liste tout le regne animalia à l'exclusion du phylum chordata. C'est justement grace aux listes que c'est simple.

[gildeluermoz]

Les listes sont plus ou moins facile à créer en fonction du besoin et de leur cohérence avec la structure de taxref. Mais les listes existent et on ne peut pas dans un contexte hyper générique présager de l'usage et de la bonne manière de s'en servir. C'est à l'administrateur de donnée d'évaluer si son choix d'usage/création de telle ou telle liste est pertinent. Et aussi d'en assumer la maintenance.

Par contre, à la base, c'est la fonctionnalité de filtrage de l'import à partir d'une liste qui me pose question.
Importer un fichier comportant toute sorte de taxons dans un jeux de données ciblé (araignées ou coléoptère par ex.) ne me semble pas relever des bonnes pratiques.
Soit l'administrateur gère ses sources en cohérence avec ses JDD soit c'est le lien metadata / liste de taxons qui contraint globalement la saisie. Et pas seulement dans le module d'import. La contrainte doit restée vraie pour tous les modules qui écrivent dans la base.
Faire faire ce travail au module d'import, via un paramètre qui n'est pas disponible en interface mais seulement via un fichier de conf me semble trop aléatoire et possiblement incohérent comme le dit @bouttier.
Sans compter que l'utilisateur qui importe n'est pas forcement adminstrateur de l'instance GeoNature et n'a donc pas la main sur la conf du module.

Si ça doit rester au niveau du module d'import, je dirais qu'il serait préférable que le choix d'une liste de taxons (ou tout autre filtre) soit une des étapes de l'import.

MAIS, la contrainte d'intégrité JDD <--> taxons est plus globale que le seul module d'import.
Est-ce qu'il ne serait pas préférable (possible ?) de faire respecter cette intégrité au niveau de la base de données via gn_meta.t_datasets.id_taxa_list ? Silencieusement, ou via la levée d'erreurs / rejet des lignes invalides.

[bouttier]

Le paramètre de configuration du module d’import a pour inconvénient supplémentaire d’être globale et non spécifique à chaque JDD.

Je suis en revanche contre une contrainte en base pour s’assurer que les données d’un JDD ne contiennent que les taxons d’une liste données car cette intégrité me semble trop lourd à garantir. Notamment, toute modification de la liste des taxons doit réévaluer les observations existantes dans les JDD associé à cette liste afin de vérifier qu’ils sont toujours valident. D’autre part, il est certain qu’il existe des modules sources ne prévoyant pas de vérifier la liste des taxons (comme le module d’import actuellement), amenant à des erreurs d’intégrités qu’il est très compliqué à gérer correctement.

[gildeluermoz]

Je suis bien d'accord, cette intégrité est très complexe et lourde à assurer.
Et donc si la base ne peut pas la garantir, l'administrateur doit savoir qu'elle n'existe pas et donc que cela relève de sa responsabilité.
La meilleure alternative me semble être de proposer, éventuellement, ce filtre en interface mais surtout pas en conf.
Et j'entends bien toute la complexité de dev que cela suppose. Donc la pertinence de maintenir cette fonctionnalité se pose ?

[DonovanMaillard]

Pour moi, le plus simple et cohérent, c'est d'appliquer la même contrainte qu'actuellement, mais au lieu de définir l'id liste au niveau de la conf du module, on reprend celle du JDD dans lequel on importe.

Ca fait peu de modifications au niveau du module, ca entretien une cohérence entre les différents module d'entrée de données (imports,saisie etc), l'utilisateur n'a pas a y toucher c'est déjà défini au niveau du JDD. C'est vraiment le plus simple et cohérent à mon sens.

A la base, cette fonctionnalité du module d'import a été faite (à ma demande) pour répondre aux besoins des instances thématiques (spécialistes papillons, amphibiens, base invertébrés etc,les exemple sont nombreux), qui permettent de ne pas avoir à pré-filtrer ses tables qui n'ont pas toujours de cd_nom pour faire des filtrages rapidement. Mais le mettre en cohérence avec le lien jdd/liste qui existe désormais serait plus clair.

[bouttier]

+1

C’est quasi-rien comme dev d’utiliser la config du JDD plutôt que du module, et c’est clairement plus cohérent (et j’adore supprimer des paramètres de config, ça simplifie les confs).