Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remplissage automatique des listes de taxons de taxhub si de nouveaux taxons sont importés #450

Open
JulienCorny opened this issue Jun 12, 2023 · 9 comments
Labels
question Further information is requested wontfix This will not be worked on

Comments

@JulienCorny
Copy link
Contributor

Bonjour à tous,

Lorsqu’on importe des observations via le module d’import, les listes de taxons de TaxHub (comme saisie_occtax) ne sont pas mises à jour s’il y a des nouveaux taxons.

Avant de voir ce qu’il serait possible de faire au niveau technique pour répondre à cette fonctionnalité, est-ce qu’au niveau métier ce serait intéressant selon vous ? ou est-ce que c’est un besoin trop rare pour l’intégrer potentiellement au module d’import ?

Au niveau technique, plusieurs points seraient à réfléchir :

  • intégration au module d’import : facultatif ou pas ? Si c’est facultatif, on peut prévoir une variable dans le toml du module (par exemple CHECK_TAXHUB_LISTS = False par défaut)
  • comment définir quelles listes de taxons de taxhub seront mises à jour ? Via une autre variable dans le fichier de configuration qui liste le nom des listes de taxons taxhub à mettre à jour (TAXHUB_LIST_NAMES?) ?
  • comment mettre à jour les listes : par une requête sql en dernière étape du processus d’import ? Cette requête comparerait le contenu des listes de taxons cibles avec la liste des cd_nom de l’import en cours, si une nouveau taxon est détecté il est ajouté aux différentes listes ? Inconvénient : rallonge le processus d’import.
@DonovanMaillard
Copy link
Collaborator

Salut Julien,

A mon sens ce fonctionnement pose question.

Les listes de taxhub peuvent être multiples, et ajouter les taxons importés à toutes les listes n'est pas pertinent (si je crée une liste des papillons du Plan national pour un projet, je n'ai pas envie qu'elle soit complétée par des imports). Idem pour des listes plus larges comme "saisie occtax", je n'ai pas forcement envie de rendre saisissable des noms importés.

Par exemple si j'importe des données de collections, les noms utilisés seront les anciens, je n'ai pas envie qu'ils soient saisissables. Dans tous les cas, avec ou sans liste, tous les noms en synthèse sont requêtables.

Je pense que ces listes sont là pour l'administration, pour alléger les listes et contrôler ce qu'on peut saisir ou non dans tel ou tel module/jeu de données. Modifier les listes me poserait bien plus de soucis que d'avantages personnellement.

Quel est le besoin d'ajouter ces taxons ? A quelles listes ? Est-ce pertinent d'ajouter tous les noms présents dans un import ?

A la limite, les ajouter à la bib_noms tant qu'elle existe, mais pas aux listes directement...

@gildeluermoz
Copy link

Je partage le point de vue de donovan. L'usage des listes est variable selon les structures. Certaines mettent dans la liste saisie_occtax tous les taxons déjà vus sur le territoire mais certaines mettent tout le possible à dire d'expert et d'autres ont des stratégies différentes.

@JulienCorny
Copy link
Contributor Author

Salut Donovan,

Merci pour tes réponses !

"Les listes de taxhub peuvent être multiples, et ajouter les taxons importés à toutes les listes n'est pas pertinent" : pas toutes les listes justement, faire un système qui permet de lister les listes taxhub qu'on veut mettre à jour à la fin de l'import (dans le fichier de config).

"Modifier les listes me poserait bien plus de soucis que d'avantages personnellement." : si on met un variable dans la config CHECK_TAXHUB_LISTS vrai ou faux, si tu veux pas tu n'actives pas l'option, avec par défaut à faux pour que ce soit désactivé. ça conviendrait pas comme ça ?

"Je pense que ces listes sont là pour l'administration, pour alléger les listes et contrôler ce qu'on peut saisir ou non dans tel ou tel module/jeu de données." : justement je trouvais que l'intérêt est là pour l'administrateur : par exemple on peut avoir besoin d'une liste 'saisie_occtax' toujours à jour pour occtax mobile sur le terrain (dans ce cas on la met à jour à la fin de l'import), mais on peut aussi avoir des naturalistes qui saisissent dans geonature et qui n'ont besoin que d'une liste restreinte de taxons (et dans ce cas on ne met pas à jour ces listes).

"Dans tous les cas, avec ou sans liste, tous les noms en synthèse sont requêtables." : je suis d'accord mais tous les administrateurs ne font pas obligatoirement des requetes directement en bdd, ils ont juste besoin de pouvoir gérer les utilisateurs, les groupes et les listes de taxons depuis les outils fournis par les interfaces utilisateurs des applis.

@DonovanMaillard
Copy link
Collaborator

par exemple on peut avoir besoin d'une liste 'saisie_occtax' toujours à jour pour occtax mobile sur le terrain

Dans ce cas, on peut saisir directement tout taxref :)

En fait, pour moi les 2 choses n'ont rien à voir.

Les listes sont destinées à rendre disponible des taxons à la saisie. C'est pas parce que j'importe des données que forcement, le taxon doit pouvoir être saisi (vieux synonymes, taxon identifiable par quelques rares experts etc). Le soucis c'est qu'en généralisant le complément à la liste saisie occtax, tu peux importer tout et n'importe quoi, y compris des taxons qui sont faux.

Si lundi tu importes un fichier qui comporte une erreur, que tu vas invalider cette donnée, tu auras rendu saisissable le taxon et tu pourras multiplier l'erreur.

Je vois pas bien le cas pratique qui peut justifier de ne pas saisir tout taxref mais d'avoir une liste qui se complète automatiquement à chaque import. (En sachant que la prochaine version du mobile qui sera publiée embarquera tout taxref, la version n'est pas encore publiée mais c'est le fonctionnement mis en place à partir des prochaines releases).

@JulienCorny
Copy link
Contributor Author

Je partage le point de vue de donovan. L'usage des listes est variable selon les structures. Certaines mettent dans la liste saisie_occtax tous les taxons déjà vus sur le territoire mais certaines mettent tout le possible à dire d'expert et d'autres ont des stratégies différentes.

Pour le coup je trouve que ça rend justement cette fonctionnalité utile : celles qui mettent dans 'saisie_occtax' tous les taxons déjà vus sur le territoire ont besoin d'avoir une liste à jour de toutes les obs faites sur le terrain donc à jour des imports faits dans la synthèse, non ?

@DonovanMaillard
Copy link
Collaborator

Je pense vraiment qu'il faut garder l'import et la saisie dissociés par rapport aux listes de taxons. Même si on peut le désactiver, je pense que c'est un paramètre et des fonctionnalités supplémentaires à maintenir, pour une fonctionnalité qui n'est pas très claire

@JulienCorny
Copy link
Contributor Author

Oui si on met tout taxref pour les listes de saisie c'est sûr que là l'intérêt des listes de saisie personnalisées n'est pas terrible :)

Mais en même temps mettre tout taxref à la saisie pourquoi pas mais là aussi ça se discute il me semble. Personnellement il me semblait que c'est pas super pratique et optimal pour la rapidité de la saisie sur le terrain d'avoir tout taxref dans la liste, même si on peut rechercher par nom les taxons. Mais je me trompe peut-être car je ne l'ai pas fait en pratique.

"C'est pas parce que j'importe des données que forcement, le taxon doit pouvoir être saisi " : j'aurais eu le raisonnement inverse, pas forcément oui mais j'aimerais bien avoir la possibilité de le faire si nécessaire.

"Si lundi tu importes un fichier qui comporte une erreur, que tu vas invalider cette donnée, tu auras rendu saisissable le taxon et tu pourras multiplier l'erreur." : à ce moment là mettre tout taxref ne va pas arranger les choses non ?

Mais bon c'est vrai qu'au final comme tu le dis Donovan l'intérêt est peut-être un peu limité par rapport au développement et à la maintenance que représente cette fonctionnalité

@camillemonchicourt
Copy link
Member

Sujet intéressant en effet, qui soulève des questions assez larges comme :

  • Le rôle des listes de taxons dans Occtax, et leurs potentiels différents usages (selon les contextes et les structures)
  • La place des taxons présents dans la Synthèse vis-à-vis des taxons saisissables dans Occtax
  • Le rôle du module Import par rapport à la Synthèse

1. Premièrement, selon moi, ce sujet n'est pas limité au module IMPORT, mais plus global au niveau de GeoNature et de son module SYNTHESE. Donc même le ticket ne devrait pas être dans le module IMPORT selon moi.
En effet le module IMPORT n'est qu'un moyen parmi d'autres d'intégrer des données dans la SYNTHÈSE (Occtax, Import SQL, Monitoring, Autres modules, Autres sources comme des API externes, etc...).
Car, il s'agirait de faire en sorte que tous les nouveaux taxons ajoutés dans des observations de la Synthèse soient automatiquement ajoutés dans la liste principale de saisie dans Occtax, pas seulement les taxons des observations intégrées dans la Synthèse par le module IMPORT.
Donc si une telle fonctionnalité devait être implémentée, ce serait au niveau de GeoNature et de la Synthèse, et pas seulement du module IMPORT.

2. En effet, le principe initial de la liste de taxons saisissables dans Occtax, est que quelques référents gèrent et maîtrisent la liste des taxons saisissables, pour garantir une maîtrise et cohérence de celle-ci et éviter un maximum d'erreurs.
En effet, dans notre contexte, on ne veut surtout pas que cette liste soit remplie automatiquement par toutes les données des partenaires (avec leurs éventuelles erreurs) et experts externes dont on importe/intègre les données dans la Synthèse.
C'est vrai aussi que cela a été particulièrement nécessaire pour l'application Occtax-mobile pour avoir une liste de taxons supportable et lisible.

3. Cependant je comprends que pour certaines structures qui ont peu de données de leur côté et en importent beaucoup, peuvent vouloir une liste limitée et cohérente, mais avec très souvent de nouveaux taxons liés à des données importées dans la Synthèse que l'on souhaite ajouter facilement et régulièrement dans la liste des taxons saisissables dans Occtax.

A voir si cette tache d'intégration dans la liste doit être automatisée ou si ce qui serait utile et pertinent ne serait pas plutôt une aide pour la gestion de cette liste, en permettant de lister facilement les taxons présents dans la Synthèse mais qui ne sont pas dans la liste des taxons Occtax, pour pouvoir les identifier facilement, et les ajouter ou non, à partir de cette info.

En SQL, il serait assez facile de faire un SELECT DISTINCT des taxons présents dans la Synthèse, et de lister ceux qui ne sont pas présents dans une liste.
En SQL toujours, il serait assez facile d'insérer manuellement ou automatiquement tous ces taxons régulièrement dans une liste, si une structure souhaite se baser sur les taxons de la Synthèse.


2 points d'attention néanmoins :

  • GeoNature dépend de TaxHub et pas l'inverse. GeoNature n'est pas censé écrire dans le schéma taxonomie de TaxHub
  • La refonte actuelle de TaxHub comprend aussi la simplification des listes de taxons, en supprimant l'intermédiaire lourd de la table bib_noms. Il sera alors plus simple de peupler une liste, sans cette intermédiaire de bib_noms

@JulienCorny
Copy link
Contributor Author

Merci pour ces précisions et réflexions.

C’est vrai que la gestion des listes de taxons sort du cadre du seul module d’import, et que le fait que GeoNature dépende de taxhub et pas l’inverse limitent la proposition faite initialement.

Donc pour l’instant le mieux serait de faire au cas par cas un script sql permettant de remplir les listes de taxons si nécessaire, avec un cronjob pour automatiser son exécution. Avec pour très bientôt une simplification du processus grâce à la suppression de la table bib_noms.

Et dans l'idéal prévoir un jour (par l’intermédiaire du backoffice admin?) une aide à la gestion des listes de taxons pour permettre leur manipulation facilement sans qu’il soit nécessaire de mettre les mains directement dans la base de données.

@camillemonchicourt camillemonchicourt added enhancement New feature or request question Further information is requested wontfix This will not be worked on and removed enhancement New feature or request labels Jun 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

4 participants