[Validation] Validation automatique des données

[mvergez]

Bonjour,

Tout d'abord, j'espère que le sujet n'a pas déjà été évoqué dans les issues (les recherches "validation" et "validation automatique" n'ont rien donné, à part : PnX-SI/gn_module_validation#5 mais qui, je crois, a dévié vers les profils de taxons plus que la validation automatique). Ensuite, je pense que c'est un grand débat mais je me lance quand même.

Introduction

Dans le cadre d'une prestation pour la DREAL Corse une validation automatique de données selon l'espèce est souhaitée.
Cette validation ne peut pas s'appuyer sur le profil de taxon pour les raisons suivantes :

• Pas assez de données pour avoir des profils de qualité
• Cette validation automatique concerne certains taxons. Donc valider un profil de 3/3 sur toutes les espèces n'est pas souhaitable.

Une des raisons en faveur d'une validation automatique est la validation d'espèces très communes et bien sûr le nombre d'observations à valider. Il pourrait éventuellement y avoir des erreurs d'observation même pour ces espèces mais cela reste à la charge de l'administrateur d'activer ou non cette validation automatique.

Proposition

Mes propositions sont encore en cours de réflexion mais je pense que je n'ai pas le choix d'utiliser un trigger pour déclencher une validation automatique dès l'insertion ou la modification d'une donnée en synthèse comme cette donnée peut provenir du module d'import/monitoring/occtax ...

Ce trigger pourrait être simple : insertion dans t_validation si le cd_nom est dans une liste d'espèce à valider automatiquement (pourquoi pas une liste taxonomique TaxHub). Cette liste pourrait figurer dans gn_commons.t_parameters

Ou plus complexe (mais cela ressemblerait plus à une usine à gaz à mon avis) : création d'une table de validation automatique contenant 2 colonnes : une foreign key vers une liste taxonomique, une foreign key vers un status de validation. Le trigger lirait dans cette table et insérerait dans t_validation si correspondance il y a. Cela permettrait d'administrer facilement la validation auto via Flask Admin par exemple.

Qu'en pensez-vous ?
Merci d'avance pour vos retours !!!

---

References

Schéma page 11 : https://www.occitanie.developpement-durable.gouv.fr/IMG/pdf/validation_pole_invertebres-_v_1_opie_cen_occitanie.pdf (dans ce cas précis, seule la validation automatique sur le critère phénologique groupe 3 est considérée)

[geobrun]

Drôle de coïncidence, j'ai effectué également des recherches hier sur le dépôt à propos du fonctionnement de la validation. J'en étais arrivé à la même conclusion que toi @mvergez : il serait intéressant d'avoir un mécanisme de validation automatique. Une validation via profil me semble plus logique, mais effectivement, comme tu l'as dit, en cas de manque de données, cela ne fonctionnerait pas. Dans l'un des sujets du dépôt, quelqu'un évoquait la possibilité de récupérer via des organismes supra (genre SINP) des listes de taxons validables automatiquement.

Le fonctionnement actuel est un peu déroutant : sachant que nous saisissons nous-mêmes la plupart de nos données, nous ne les validons pas. Elles ont donc par défaut le statut "En attente de validation" quand nous les transmettons au SINP. Par contre, nos quelques données qui viennent d'observateurs extérieurs passent elles par le module Validation et sont donc paradoxalement validées !

[camillemonchicourt]

La valeur attribuée par défaut aux données saisies peut être modifiée.
De notre côté, on a changé celle-ci pour que toutes les données saisies par les agents du PNE soient validées par défaut et ne pas perdre de temps à les regarder une par une, sachant qu'ils savent ce qu'ils font ou demandent aux chargés de mission référents si ils ont un doute.
On fait parfois de la relecture, ou des analyses globales ou des corrections globales si un taxon a été mal nommé depuis un certain temps, mais pas des validations une par une.

Concernant une potentielle validation automatique, les profils de taxons sont en effet un outil pertinent pour cela, et quand ils ont été mis en place leur potentielle utilisation pour de la validation automatique avait été évoquée.

Ils s'appuient d'ailleurs sur des réflexions des SINP ou réseaux de différentes régions.

Uniquement se baser sur une liste de taxons me semble assez léger et arbitraire.

Dans tous les cas, il y aura certainement des contextes et approches variés, donc il faut un mécanisme simple, léger et adaptable/activable/désactivable.

[mvergez]

Merci pour vos retours !

Ce serait effectivement une bonne idée de récupérer une liste de taxon du SINP ! Après l'objectif est que chacun puisse faire sa propre liste.

Je pense @camillemonchicourt que la validation sur une liste de taxon est plus pour valider les données sur des espèces qui sont beaucoup observées et dont le statut de validation est au final toujours le même. Cela permet de gagner du temps sur la validation d'un grand nombre d'observation.

Je vais faire quelques tests d'implémentation et je vous tiens au courant.

[mvergez]

J'ai fait quelques tests, je suis allé "loin" dans l'implémentation mais peut-être que ça pourra répondre à la contrainte suivante (à part peut-être l'aspect léger) :

Dans tous les cas, il y aura certainement des contextes et approches variés, donc il faut un mécanisme simple, léger et adaptable/activable/désactivable.

Voici les étapes :

Création d'une nouvelle table gn_commons.t_validations_auto

Cette nouvelle table permet d'associer des listes taxonomiques à des status de validations.

CREATE TABLE gn_commons.t_validations_auto
(
	id_liste int NOT NULL,
	id_nomenclature_statut_valid int NOT NULL,
	CONSTRAINT fk_id_liste
            FOREIGN KEY(id_liste) 
            REFERENCES taxonomie.bib_listes(id_liste)
            ON UPDATE CASCADE 
           ON DELETE CASCADE,
	CONSTRAINT fk_id_nomenclature_statut_valid
            FOREIGN KEY(id_nomenclature_statut_valid) 
            REFERENCES ref_nomenclatures.t_nomenclatures(id_nomenclature)
            ON UPDATE CASCADE 
            ON DELETE CASCADE
)

ALTER TABLE gn_commons.t_validations_auto 
ADD CONSTRAINT check_t_validations_auto_id_nomenclature_statut_valid CHECK (ref_nomenclatures.check_nomenclature_type_by_mnemonique(id_nomenclature_statut_valid,
'STATUT_VALID'::CHARACTER VARYING)) NOT VALID

Création d'une fonction trigger gn_commons.fct_trg_add_auto_validation_status()

Inspiré de gn_commons.fct_trg_add_default_validation_status()

Elle permet, depuis le cd_nom d'une nouvelle entrée dans la synthèse, de trouver un statut de validation grâce à la table précédemment créée.

• Si aucun statut de validation n'est trouvé, celui par défaut est attribué
• Si l'objet en synthèse a déjà ce statut, la fonction s'arrête là
• Si le statut de validation trouvé est différent de celui actuel de l'objet en synthèse, une nouvelle entrée dans la table t_validations est insérée.

Il serait également possible de faire un select 1 from gn_commons.t_validations_auto limit 1; pour mettre fin à la fonction prématurément.

CREATE OR REPLACE
FUNCTION gn_commons.fct_trg_add_auto_validation_status()
 RETURNS TRIGGER
 LANGUAGE plpgsql
AS $function$
DECLARE
	theid_nomenclature_statut_valid int;

thecomment TEXT := 'auto = validation automatique sur liste taxonomique';

thedefault_nomenclature_value int := gn_synthese.get_default_nomenclature_value('STATUT_VALID'::CHARACTER VARYING);

BEGIN
--Récupérer le cd_nom
	SELECT INTO theid_nomenclature_statut_valid
		tva.id_nomenclature_statut_valid
        FROM
		gn_commons.t_validations_auto tva
        JOIN taxonomie.bib_listes bl ON
		tva.id_liste = bl.id_liste
        JOIN taxonomie.cor_nom_liste cnl ON
		bl.id_liste = cnl.id_liste
        JOIN taxonomie.bib_noms bn ON
		bn.id_nom = cnl.id_nom
        JOIN ref_nomenclatures.t_nomenclatures tn ON
		tn.id_nomenclature = tva.id_nomenclature_statut_valid
        WHERE
		cd_nom = NEW.cd_nom
        ORDER BY
		tn.cd_nomenclature
        LIMIT 1;

        IF theid_nomenclature_statut_valid ISNULL
	        THEN
		        theid_nomenclature_statut_valid = thedefault_nomenclature_value;
        END IF;

        IF NEW.id_nomenclature_valid_status = theid_nomenclature_statut_valid
                THEN 
	                RETURN NEW;
        END IF;
        --Insertion du statut de validation et des informations associées dans t_validations
	INSERT INTO gn_commons.t_validations 
        (uuid_attached_row,
	id_nomenclature_valid_status,
	id_validator,
	validation_comment,
	validation_date)
        VALUES(
	          new.unique_id_sinp,
	          theid_nomenclature_statut_valid, 
	          NULL,
	          thecomment,
	          NOW()
	 );

        RETURN NEW;
END;

$function$
;

Création du trigger gn_synthese.tri_insert_update_cd_nom_validation_synthese

Création d'un trigger seulement sur le cd_nom

CREATE TRIGGER tri_insert_update_cd_nom_validation_synthese AFTER
INSERT
    OR
UPDATE
    OF cd_nom ON
    gn_synthese.synthese FOR EACH ROW EXECUTE FUNCTION gn_commons.fct_trg_add_auto_validation_status()

Ce qu'il reste à faire

• Valider cela avec vous !
• Voir si les performances sont grandement impactés quand la validation automatique est activée (normalement le select dans la fonction est rapide s'il n'y a aucune entrée dans la table gn_commons.t_validations_auto)
• Vérifier les noms des colonnes (par ex : id_nomenclature_statut_valid vs id_nomenclature_valid_statut)
• Créer une migration
• Ajouter une section dans Flask Admin et rendre disponible la table gn_commons.t_validations_auto
• Ajouter des tests

Ceci est une première implémentation mais toute remarque est bienvenue

[geobrun]

@camillemonchicourt : effectivement, je n'avais pas pensé à changer la nomenclature par défaut... Je vais m'occuper de ça, merci !

[camillemonchicourt]

@mvergez, déjà si on créé une table qui part du principe que la validation automatique se base sur une liste de taxons, on est dans une approche très spécifique de votre contexte et qui, je pense, ne sera pas partagée.

Cela voudrait dire = La validation automatique dans GeoNature c'est basé sur des listes de taxons... 🤔

Donc pas cohérent avec ce qui a été proposé, discuté et construit autour des profils de taxons.

[mvergez]

La table est une idée, après elle peut-être renommée autrement, peut constituer une première brique de ce qui sera la validation automatique dans GeoNature dans le futur.

Le concept était de ne pas se fier exclusivement aux profils de taxons. Car valider automatiquement un profil de taxon est risqué car dépend de la qualité des profils de taxons. De plus, on pourrait souhaiter que cette validation sur profil ne s'applique pas sur tous les taxons.

Si on prend comme référence ce schéma (qui est disponible dans le pdf joint à mon premier message) :

Il y a 2 types de validations automatiques, un exclusivement sur la phénologie et un sur ce qui se rapproche du profil de taxons. Ces deux types ne sont donc pas incompatibles au contraire !

[DonovanMaillard]

Bonjour Maxime,

Les profils de taxons doc ici sont déjà prévus pour calculer les profils seulement sur des taxons sur lesquels on a suffisamment de données validées, car les altitudes extremes etc sont exclues. Du coup on ne calcule normalement des profils complets que si les données valides sont suffisamment nombreuses :

Il faut donc (1/[1- proportion_kept_data /100])+1 données pour que des altitudes fiables soient calculées, soit :

101 données minimum par période/stade si proportion_kept_data =99

51 données minimum par période/stade si proportion_kept_data =98

21 données minimum par période/stade si proportion_kept_data =95

11 données minimum par période/stade si proportion_kept_data =90

3 données minimum par période/stade si proportion_kept_data =51

Du coup, sans passer par des listes de taxons, tu peux déjà jouer sur la fiabilité de tes profils pour faire de l'auto validation à partir de cette info là.

Ensuite, la validation auto n'est pas encore mise en place au niveau de geonature. On peut imaginer un garde-fou optionnel :

• J'ai un paramètre pour activer ou non la validation auto sur la base des profils d'espèces (score = 3 --> je valide)
• Si oui, je valide tout, si non je ne valide rien
• Puis éventuellement pourquoi pas dans les paramètres, une liste de taxons taxhub : si une liste est renseignée on ne valide sur la base des profils que les taxons dont le cd_nom est dans la liste. Si le paramètre n'est pas renseigné, alors on valide tout (ou rien) selon le paramètre précédent ?

[DonovanMaillard]

mais du coup ca passerait pas par un trigger, mais par une tache celery lancée périodiquement ? je pense que dans tous les cas c'est préférable, le fait d'avoir des triggers en direct sur la synthèse risque de poser des soucis de time out dans les imports de masse, les liens gn2pg etc

[mvergez]

EDIT : pas de critère phénologique, erreur de ma part

Salut Donovan,

Merci pour ton retour.

L'objectif ici est de ne pas se baser sur les profils de taxons. Car cela peut être dangereux car s'applique à tous les taxons. Le but est tout d'abord de se focaliser sur une liste d'espèces.
Et de plus, dans ce cas précis, les profils de taxons ne sont pas d'assez bonne qualité pour se baser dessus.
Donc une validation auto sur les profils de taxon se fera si besoin via une autre issue/PR en complément ou en parallèle de la validation auto.

Je suis d'accord avec toi pour les triggers dans la synthèse. Le souci c'est qu'une validation automatique via tache cron/celery n'a pas vraiment de sens. Il faudrait attendre quelques heures voir 1j avant de voir l'état des validations. Le souci est que l'insertion en synthèse ne passe pas par l'ORM dans tous les cas (occtax par exemple passe par un trigger si je ne dis pas de bêtises, le module d'import passe par l'ORM). Si on passait à chaque fois par l'ORM, on pourrait avoir un event qui déclenche effectivement une tâche Celery qui ferait les opérations sans bloquer l'insertion en synthèse.
Donc je ne vois pas comment faire autrement aujourd'hui.

Une validation automatique va forcément ajouter des opérations, donc forcément dans le cas d'un import en masse, ce dernier sera plus long. Mais à ce moment là il faudrait aussi supprimer les trigger de calculs auto de la cor_area_synthese, sensibilité etc...

[mvergez]

Salut !
Suite à des discussions et réflexions, je suis d'accord avec vous qu'il serait préférable de faire une tâche celery lancée périodiquement, qui irait modifier les statuts de validation. Cela permettrait déjà d'être du côté Python et donc de faire des choses plus personnalisables et configurables.

Ensuite on peut essayer de partir sur ce que tu proposes @DonovanMaillard en mettant en place une liste taxhub optionnelle permettant de valider uniquement sur certaines espèces.

Merci encore pour vos retours ! Je vous tiens au courant de l'implémentation

[mvergez]

Bien le bonjour,

Je reviens vers vous après une petite réflexion sur le sujet.

Je pensais donc faire une tâche Celery qui appellerait une fonction SQL (période d'exécution à définir en configuration). Cela pour que chacun puisse intégrer ses propres règles de validation automatique. Au départ je pensais faire uniquement en Python mais ça rebuterait quelques personnes je pense.

Après est-ce qu'on fait une seule fonction SQL paramétrable depuis la configuration ou est-ce qu'on donne la possibilité de faire plusieurs fonctions SQL et là c'est une table et une section dans Flask Admin ?

Par défaut on pourrait ajouter cette fonction SQL pour se baser sur les profils de taxons mais désactivée en configuration.

Qu'en pensez-vous ?

Merci beaucoup d'avance pour vos retours !

[camillemonchicourt]

Oui cette approche me semble intéressante, générique et adaptable.

[andriacap]

Bonjour,

Par rapport à la validation automatique des données , il a été mentionné de réaliser une tâche celery.
Est ce que cette tâche doit être mis dans gn_commons ? (chemin : geonature/backend/geonature/core/gn_commons/tasks.py )

Merci

[camillemonchicourt]

Salut,

Cela dépend de la solution retenue.
On partira sur un fonctionnement de base désactivé, s'appuyant sur les profils de taxons, limitables à une liste de taxons.
Voire complètement adaptable pour ne pas du tout passer par les profils de taxons ?

Pour l'endroit où ranger ça dans le code, je n'ai pas d'avis.
Ça dépend de ce que cela concerne ? Peut-être plutôt dans le module VALIDATION ? Ou dans la partie PROFILS DE TAXONS ?

[andriacap]

Salut Camille,

Si des utilisateurs veulent customiser à 100% leur validation automatique ça pourrait être dans un premier temps juste rajouter 2 paramètres en configuration GN de type :

 VALIDATION_CRONTAB = fields.String(load_default="0 1 * * *")
 VALIDATION_ENABLED = fields.Boolean(load_default=False)

Puis dans la tâche celery l'éxécution d'une fonction sql (à définir quel schema doit porter cette fonction , gn_commons, gn_profiles ?)

Création d'un fichier sql dans lequel on propose par défaut une fonction d'autovalidation basé sur le score de profil de taxon (par exemple : si score de 3/3 alors on passe le statut de validtion à probable)

Du coup on crée une migration alembic qui crée cette fonction par defaut et on precise dans le fichier de config GeoNature que l'activation du paramètre VALIDATION_ENABLEDpermet l'auto validation via la fonction par défaut et que s'ils veulent une auto-validation particulière alors il faut changer cette fonction ?

Coté utilisateur ça permet de paramètrer ou non l'auto validation facilement et pour l'aspect personnalisation de validation l'utilisateur peut editer la fonction en base de données si celle par défaut ne convient pas .

Voilà pour une première proposition , n'hésitez pas à rebondir

[DonovanMaillard]

J'adopterais cette même logique : un paramètre générique, qui planifie une fonction SQL par défaut qui s'appuie sur les profils.

Ca permet sur une instance "non customisée" d'avoir une validation automatique basée sur les profils, activable facilement. Sans bloquer la validation custom pour ceux qui le souhaitent (après chacun peut se faire un cron avec sa fonction custom, c'est peut-être mieux que d'aller toucher cette fonction par défaut, sinon à chaque MAJ il faudra reporter ses modifs perso).

[camillemonchicourt]

Si on met des paramètres, à renommer AUTO_VALIDATION_CRONTAB et AUTO_VALIDATION_ENABLED.

Oui pour que le fonctionnement de base s'appuie sur les profils de taxons.

Pour moi ça doit aller dans gn_profiles.

Par contre si on met ça dans une migration c'est bien, mais si les gens se modifient la fonction, et qu'on veut la faire évoluer, l'améliorer, alors on fera une autre migration qui le recréé et on va écraser leurs modifications.

Donc plutôt à gérer à part si on veut se faire son truc spécifique ?

[andriacap]

Du coup est ce qu'il serait pas intéressant sinon de créer une commande geonature de type : geonature update auto_validation_function avec un argument à passer pour le nom du fichier sql personnalisé ? Donc à préciser dans la doc que si l'utilisateur veut une fonction de validaton automatique différente de celle par défaut il doit éxécuter cette commande ?

[jpm-cbna]

Par contre si on met ça dans une migration c'est bien, mais si les gens se modifient la fonction, et qu'on veut la faire évoluer, l'améliorer, alors on fera une autre migration qui le recréé et on va écraser leurs modifications.

Est ce qu'il ne serait pas possible d'avoir une fonction SQL par défaut maintenu dans le code de GeoNature mais que la tâche Celery recherche aussi la présence d'une autre fonction utilisateur. Si la tâche Celery trouve la fonction SQL utilisateur, elle l’exécute à la place de la fonction par défaut ?

Le nom de la fonction utilisateur pourrait correspondre au nom de la fonction par défaut mais avec le suffixe "_custom" par exemple. Ou alors elle pourrait être défini dans un paramètre du style AUTO_VALIDATION_CUSTOM_SQL_FUNCTION...

[camillemonchicourt]

Oui je pense que faire une commande geonature update auto_validation_function n'est pas vraiment une pratique commune et cela compliquerait les choses car chacun devrait exécuter cette commande, même pour utiliser la fonction de base.

L'idée d'avoir une fonction de base proposée dans une migration et maintenant, mais d'utiliser une fonction custom si elle existe me semble intéressante.

Dans tous les cas, en demandant par ci par là, j'ai trouvé personne d'autre qui baserait sa validation automatique uniquement sur une liste de taxons.
Mais par contre, j'ai croisé pas mal d'approches différentes et de règles qui pourraient être à adapter selon les contextes, les territoires, les approches (exemple : valider toutes les observations de tel espèce dans tel département entre tel et tel mois).

[LafageDenis]

Bonjour,

Je me permets de squatter le fil, car ma question est liée, mais si besoin, je peux ouvrir un autre ticket...

J'aurais aimé savoir s'il était envisageable 'd'injecter' des profils et non de les calculer à partir des données en base. L'idée serait d'utiliser les données du SINP régional et de partenaires pour calculer les profils et de les mettre à dispo pour améliorer les indices de confiances de tous les partenaires utilisant Géonature et d'avoir une meilleure base pour la validation auto.

Merci

[camillemonchicourt]

Oui il vaut mieux un autre sujet dédié, sinon on va discuté de trop de choses différentes ici.

[jacquesfize]

Bonjour à tous,

La PR #2768 de @andriacap qui propose un processus de validation automatique est intégrée dans la branche develop. Cette fonctionnalité sera comprise dans la version 2.14 de GeoNature.

Voir la doc sur le sujet :

GeoNature/docs/admin-manual.rst

Line 2389 in a295fe6

Validation automatique

[camillemonchicourt]

La fonction de validation automatique des données a été intégré dans la version 2.14.0.
Documenté ici : https://docs.geonature.fr/admin-manual.html#validation-automatique