Open DonovanMaillard opened 3 years ago
camillemonchicourt
commented
3 years ago En lien avec https://github.com/PnX-SI/GeoNature/issues/445 ?
Dans tous les cas si on calcule des cd_noms, je verrai bien une étape de listing des correspondances qui ont été faites, pour les vérifier/valider.
Ou alors que ce soit une étape à part de pouvoir retrouver les cd_nom des données qui n'en avaient pas ?
DonovanMaillard
commented
3 years ago Oui, à mettre en lien en effet, j'avais pas vu les travaux de Gil sur ce point.
Avec la fonction que j'ai faite ici, aucun risque d'erreur puisqu'il ne réconcilie que les cas qui n'ont pas d'ambiguité. Tous les cas ambigus sont laissés NULL donc ressortiront avec les données en erreur car un champs obligatoire est vide.
Du coup on serait pas au top du top, on ne fournit pas d"outil pour réconcilier les cas litigieux, mais au moins on ne risque pas d'introduire des cd_nom erronés. Ca ne ferait pas d'étape supplémentaire et rien à controler du coup dans l'idée. Par contre comme le dit Gil, on est à quelques minutes pour 5.000 lignes par exemple.
jpanijel
commented
3 years ago Soit mon nom latin a plusieurs cd_nom possibles, mais ils appartiennent tous au même cd_ref --> Je renvoie le cd_ref en question (on prend le nom valide à date de l'import)
Cette approche est fortement déconseillée au niveau de la plateforme nationale du SINP qui ne souhaite pas que les cd_ref soit utilisés à la place des cd_nom. Mis à part ce correctif, je trouve la fonctionnalité très utile pour les utilisateurs et complémentaire avec celle citée par Camille. A voir effectivement comment on gère les gros volumes de données. Peut-être pourrait on afficher clairement qu'il s'agit d'une aide au "nettoyage" des données et non un substitut à la standardisation et à l'utilisation des référentiels. Je penche donc pour un limite raisonnable et fixe du nombre de réconciliations possibles par fichier.
DonovanMaillard
commented
3 years ago Sur ton correctif, comment doit-on gérer le cas d'un nom latin sans auteur ? A quel cd_nom doit-on le rattacher en l'absence d'infos plus précises ?
Fixer le nombre de réconciliations est peut-être très restrictif, mais on peut imaginer une alerte en effet disant que c'est une fonctionnalité d'aide, qui ne résout pas tous les soucis, et qui prend du temps... à moins d'avoir une fonctionnalité plus performante que ce que j'ai fait (qui reste une fonctionnalité simpliste à ce stade).
DonovanMaillard
commented
3 years ago @jpanijel je vais me pencher sur l'ajout de cette fonctionnalité prochainement. Aurais-tu un moment pour qu'on échange sur la méthodologie a adopter pour ces réconciliations ?
Merci d'avance !
jpanijel
commented
3 years ago @DonovanMaillard @camillemonchicourt
Pour info le script taxrefmatch est désormais diffusé en accès public: https://outils-patrinat.mnhn.fr/gitlab/ums-patrinat/taxrefmatch
Bonne journée, Judith
camillemonchicourt
commented
3 years ago Ah excellent, bonne nouvelle, merci.
J'ai créé une fonction "match_binomial_taxref" qui permet de récupérer le cd_nom d'un taxon à partir de son nom latin. La logique de la fonction est la suivante :
Ca limite les erreurs et ca évite quelques coquilles que fait aujourd'hui taxref match (exemple sur tettigonia cantans, taxrefmatch renvoie une cigale et non une sauterelle). En revanche, c'est très lent (et encore, j'ai remplacé ILIKE lb_nom par = lb_nom pour gagner du temps) ! Ma réconciliation du nom source se fait avec soit lb_nom soit nom_valide (avec ou sans auteur du coup).
Est-ce qu'il vous semble souhaitable de mettre un booléen "générer le cd_nom à partir du nom", qui s'il est actif, ajoute un champs gn_cd_nom et y applique la fonction pour calculer les cd_nom ? A noter qu'on peut fonctionner comme les altitudes etc, avoir un champs gn_cd_nom renseigné par le cd_nom source s'il existe et ne calculer que les manquants par exemple. Maintenant que le module envoie un mail après les checks, c'est peut-être moins gênant d'avoir des fonctions longues en cours de processus...