[Validation et saisie] Création de profils d'espèces valides

[DonovanMaillard]

Bonjour,

Après le stage de Elsa Guilley (PnX-SI/gn_module_validation#5 (comment)), et après échanges avec @camillemonchicourt et @jbrieuclp , nous sommes en train de nous pencher sur la question de la validité/cohérence des données, pour :

• Guider la validation dans le module validation
• Générer des alertes lors de la saisie de données qui ne répondent pas aux connaissances déjà disponibles sur l'instance

Le but de ces profils est de connaitre les informations déjà valides de l'instance pour guider la validation ou la saisie de nouvelles données, en s'appuyant sur :

• Aire de répartition déjà connue
• Phénologies (pas de temps retenu actuellement -> semaine)
• Classes altitudinales
• Nombre d'observations pour chaque combinaison phénologie/classe altitudinale
• Nombre d'observations valides de l'observateur pour l'espèce donnée
• • autres infos sur le taxon (altitude min, max, première observation, dernière observation etc).

Pour ce faire, je propose le mcd suivant (on pourra naturellement revoir les noms de tables et vm pour plus de lisibilités si besoin) :

Avec la t_param_valid_profils :
Pour chaque groupe 2 inpn, on peut définir la valeur en m du tampon à appliquer autour de chaque obs pour définir une aire de répartition valide. Par exemple, 5000m pour les oiseaux, 1000m pour les insectes ,100m pour les angiospermes.
Paramétrable et ajustable pour chacun donc, selon notamment la complétude de sa base, la taille de son territoire et le niveau d’exigence souhaité par exemple.
On peut aussi définir si, pour un groupe 2 inpn donné, il faut tenir compte du stade ou non dans l’analyse de la phénologie (par défaut, non pour les plantes, oui pour les insectes par exemple)

Avec la t_altitude_range:
Tenir compte de la phénologie sans tenir compte de l’altitude en zones de montagne est problématique, mais tenir compte de l’altitude comme une variable continue complexifie trop les choses. J'ai donc fait le choix de discrétiser la variable.
Par défaut : 3 catégories larges qui permettent de ne pas poser de soucis pour les utilisateurs en plaine et qui restent simples et cohérentes au niveau écologique et phénologique pour la suite :
Etages planitiaires et collinéens : 0-700m
Etages montagnards et subalpins : 701-2000m
Etages alpins et nivaux : 2001-4811m
Naturellement, c'est paramétrable pour les plus pointus, ou ceux qui ont des jeux de données assez complets pour adopter un pas plus fin.

Avec la vm_valid_profil (180.000 données 2700 taxons, 1mn48 de calcul)
On stocke les infos simples et valides de notre instance, qui sont liées à un taxon dans son ensemble (cd_ref) :

• Aire de répartition valide (on joint tous les buffers de toutes les observations valides avec le rayon défini dans la t_param)
• altitude min (informatif)
• altitude max (informatif)
• date de la première observation (informatif)
• date de la dernière observation (informatif)
• nombre de données déjà valides pour ce taxon (informatif)

Avec la vm_cor_taxa_phenology (quelques dizaines de secondes aussi)
On stocke pour chaque cd_ref les combinaisons valides de :

• semaine + classe d'altitude + éventuellement stade de vie
• le nombre de données valides pour chaque combinaison

Je n'ai pas encore implémenté le fait de tenir compte ou non du stade par exemple mais ca viendra, ces 4 premiers éléments sont fonctionnels dans mes tests. Ces VM seraient rafraichies par un cron.

Je prévois d'y ajouter une vue "v_score_unvalidated_data" qui permet, pour chaque donnée en attente de validation dans la synthèse, de vérifier si :

• la donnée tombe bien dans l'aire de répartition valide connue de son taxon
• la combinaison numéro de semaine / altitude / éventuel stade tombe bien dans une combinaison valide

Pour ne pas trop complexifier les choses et avoir des éléments de phénologie un minimum synthétisés/groupés, le pas de temps "semaine" est actuellement utilisé dans mes tests. Mais ca doit pouvoir se paramétrer pour utiliser la date précise, la semaine, le mois...

A ce stade, le but est donc de ne comparer la phénologie d'une chenille uniquement avec les connaissances des autres chenilles en termes de phénologie, mais pas en terme de répartition de l'espèce (qui se calcule au niveau du taxon donc pour toute l'espèce). Le bémol c'est que du coup, les stades non renseignés seront comparés aux autres non renseignés, mais pas le choix (et on avait qu'à saisir le stade :) )

Camille me proposait de prévoir des infos complémentaires dans la t_paramètre pour définir les statuts de validation qu'on considère "valides" ou non pour calculer ces règles.
Je propose d'y ajouter aussi des paramètres de précision : par exemple, ne pas utiliser les données trop imprécises au niveau date (plus de 30j entre date_min et max, on ignore au moment de définir le profil), ou au niveau altitudinal (une donnée avec plus de 200m entre alt_min et max, on ignore). Le but est de définir des profils avec plus ou moins de marge d'erreur, mais de pas aller trop loin non plus pour ne pas compléxifier trop les choses.

Utilisations coté interface
VALIDATION :
La dernière vue (v_score) pourrait afficher une pastille de couleur sur la liste des observations en attente de validation, pour attirer l'attention sur les données qui ne correspondent pas aux connaissances valides de l'instance.

La vue (score) permet aussi, sur la modale d'info, d'avoir une sorte de "checklist" des variables qui sont, ou non, cohérentes par rapport aux connaissances de l'instance.

Les VM permettraient de contextualiser une donnée en cours de validation par rapport à l'aire de répartition valide (projetée sur la carte en plus de la géométrie de l'obs en cours de validation) et à la phénologie valide (graphique qui illustre, pour la ou les classes d'altitudes concernées, les phénologies connues, en projetant la donnée en cours de validation par dessus).

SAISIE :
Les modules de saisie pourront appeler ces vues matérialisées lors des saisies pour faire des alertes si on tombe hors de l'aire de répartition d'un taxon (calculable dès la saisie de l'occurrence), ou hors de la phénologie (calculable lors du dénombrement).

La partie interface ferait l'objet d'une prestation de notre part. La partie base sera mise en place en amont de la prestation pour gagner du temps.

Evolutions possibles : le format proposé ici permet quelques paramétrages selon les besoins de chacun, mais il est aussi assez souple pour prévoir à terme de nouvelles variables à vérifier : si on a une couche d'habitats dans notre instance on peut imaginer par exemple une nouvelle variable dans notre checklist : est-ce que ma donnée tombe, ou non, sur les milieux habituels par exemple.

[DonovanMaillard]

En lien avec ce ticket

[DonovanMaillard]

Comparatif avec le travail entamé par Elsa :

• L'aire de répartition valide est basée sur un buffer autour des observations, et non plus sur un liste de communes. Permet de ne pas faire dépendre une aire de répartition connue d'un découpage administratif quelconque, et du coup, les profils sont indépendants du ref_geo.

• Les dates sont traitées avec un pas de temps à la semaine comme dans la proposition ci-dessus

• Les altitudes et les dates (semaines) sont traitées sous forme de combinaisons, et non plus de manière décorrélé, ce qui est un peu plus complexe mais qui offre une meilleure finesse d'un point de vue écologique

• Dans la proposition d'Elsa, elle tenait compte des bornes d'effectifs. Les effectifs ne sont pas pris en compte dans ma proposition. A voir s'il faut le réimplémenter, ce n'est pas compliqué. C'est un avis personnel, je ne suis pas sur que ca serve à la validation...

• Elsa stockait la liste des observateurs. Dans ma proposition, on ne stocke plus la liste mais on regarde le nombre de données valides faites par cet observateur (vue score).

• Dans le travail d'elsa, un vrai score était calculé par une fonction. Dans ma proposition, on a une checklist de différentes variables et on a une simple pastille de couleur pour savoir si tout matche ou non (et éventuellement checklist détaillée sur la modale d'info de la donnée dans le module validation). A voir s'il faut prévoir effectivement le calcul d'un score en plus ou à la place de la proposition ci-dessus.

Le reste de son travail consistait à une fonction qui validait automatiquement les données. C'est lié, mais pas forcément l'objectif visé ici. (mais effectivement je prévois d'utiliser le travail ci-dessous pour automatiser en partie notre validation, peut être à discuter dans un second temps quand on aura des profils :) )

[jbdesbas]

Salut,
Très intéressant comme travail. J'y avais également planché il y a quelques temps et discuté brièvement avec Elsa. Voici la démarche vers laquelle j’étais partie (qui recoupe pas mal la tienne) :

• Établir une liste de tests (distribution, phénologie, etc..). Dans la base, chaque test est traduit en une fonction du type maFonctionTest(id_synthese) --> boolean . Les fonctions peuvent donc être également utilisées dans des scripts de validation automatique et/ou de masse.

• Les paramètres des tests sont définis dans une table de règles (à la manière de t_sensitivity_rules ), avec des paramètres pour chaque cd_nom (+ bio_statut et stade de vie), qui s'applique également aux taxons de rang inférieur. Il est possible de surcoucher les paramètres (par exemple donner une un paramètre X pour la classe Aves, et de surcoucher cette valeur pour une espèce d'oiseaux particulière).

• Une VM pour pré-calculer les valeurs seuils des test à partir de gn_synthese et de la table de règles

• Un test avec des paramètres NULL pour un taxon retournera toujours NULL (test non pertinent)

• Concernant la période, je suis parti sur un système de 5 jours (pintade ? ^^) : le plus gros avantage c'est qu'une année est divisible par 5, donc pas de prob pour les obs de fin d'année. La fonction que j'avais écrit regardait si le nombre d'obs moyen de la pintade d'observation été très (X% paramètrable) supérieur au nombre moyen d'obs des autres pintades.

Je ne sais pas si la discussion à déjà été soulever mais je pense que l'utilisation de group2inpn est à éviter au maximum dans geonature. L'utilisation des cd_nom (ou liste de cd_nom) et de l'arbre taxonomique offre beaucoup plus de souplesse que group2inpn, très arbitraire, propre au muséum et au Taxref.
Je te rejoins bien sur l'intérêt de pouvoir facilement ajouter de nouveaux test et variables.
Selon les valeurde paramètres choisies, les testes peuvent servir de contrôle de cohérence (détecter les obs clairement aberrantes) ou de validation (valider les obs typiquement dans la norme).

[DonovanMaillard]

Merci @jbdesbas pour ton retour.

Suite à notre appel téléphonique, quelques retours sur nos échanges.

• On part bien tous les deux dans la même idée d'avoir un système qui "check" certaines variables : pour le moment, répartition et phénologie. Comme tu l'indiques, ça passera par des fonctions et pas uniquement par une vue (la vue appelera ces fonctions). Ca sera plus lisible et les fonctions pourront servir pour les systèmes d'alerte au moment de la saisie (tandis que la vue s'appuie sur ce qui est déjà en synthèse).

• Plutôt que le groupe2inpn, on s'appuiera bien sur une variable cd_nom. On stockera des cd_nom de phylum ou de regne par exemple par défaut, et les fonctions de taxhub permettront de lister les cd_noms enfants. On pourra donc au sein de nos instances définir des règles plus précises pour tel groupe que pour tel autre.

• Dans un premier temps pour rester rapide je vais commencer par travailler en partant du principe que chaque cd_nom n'a qu'une règle, on pourra évoluer ensuite pour le surcouchage quand c'est nécessaire, en prenant la règle la plus proche de l'espèce (basé sur bib_taxref_rang).

• Une VM calculera bien les profils valides (une vm avec l'aire de répartition connue, une VM avec la phénologie, on peut imaginer à terme une VM avec les habitats ou toute autre information (critères de déterminations requis ou autre).

• Une vue finale permettra de contenir les résultats de chacun de ces "check" pour les données en attente de validation.

• Le pas de temps phénologie ne sera pas bloqué sur un pas de temps d'une semaine mais sera paramétrable. On peut imaginer d'avoir un pas de temps de 366j pour le retard ou les arbres, observables toute l'année (donc forcement l'observation tombera dans ce pas de temps de 366j). Ou de 5j pour les insectes etc. Ca donne plus de souplesse aussi au regard de l'instance de chacun, ses spécialités et son exigence pour la validation. (fait !)

• Un test avec un paramètre nul : pour le moment une valeur par défaut est rentrée, à voir s'il faut ignorer la variable à checker dans ces cas là.

• Pour la question des X% d'observations à telle période, trop complexe, on oublie pour cette première mouture.

Coté prestations, je prévois de faire avancer les choses au début du second semestre (c'est bientôt!) pour implémenter ces connaissances là coté interface.
L'idée est simplement de fournir des VM avec les infos valides à considérer, et une vue qui fait la checklist des différentes variables vérifiées ou non. C'est sur ces VM que l'interface prendra ses infos, et l'absence d'info amènera simplement à une absence d'aide coté validation.

Ca nous laissera donc toute la liberté d'implémenter de nouveaux paramètres, de nouveaux seuils etc par la suite, dès lors que tout ça se passe en amont de la création des différentes vues ui alimenteront l'interface :)

Dans les paramètres (globaux, pas forcément par taxon), je pense ajouter des seuils pour les surfaces maximales, les imprécisions temporelles maximales (edit : plutôt utiliser les paramètres qui définissent le buffer et le pas de temps de la phénologie, pour rester cohérents et ne pas multiplier les paramètrages), ou le rang taxonomique maximal des données dont on tient compte pour produire les profils : ca permettra de ne pas établir des profils sur la base de données à la famille avec une année seule, même si celle-ci est considérée valide car vient de la biblio ou d'une collection par exemple.

Je pense qu'on va pouvoir s'arrêter là sur la complexité le temps que cette première brique soit posée :)

Merci donc à @jbdesbas pour ces avancées

[camillemonchicourt]

Un travail calculant les min et max de chaque taxons avait été initié par @gildeluermoz :

• https://github.com/PnX-SI/GeoNature/blob/master/data/core/synthese.sql#L493
• https://github.com/PnX-SI/GeoNature/blob/master/data/core/synthese.sql#L566
• https://github.com/PnX-SI/GeoNature/blob/master/data/core/synthese.sql#L584

Le trigger qui lançait ces calculs avait été désactivé car il causait des erreurs et car ce n'était pas abouti. A supprimer si le travail initié ici remplace cela.

[DonovanMaillard]

Bonjour à tous,

Une première mouture de ces profils a été mise en place :

• Calcul des aires d'occurrences et phénologie de chaque taxon
• Prise en compte des altitudes (nombre de classes paramétrables)
• Prise en compte des stades de vie activable ou non
• Paramétrage de la précision géographique (distribution) et temporelle (phénologie)
• Paramétrages possible au niveau du cd_ref (n'importe quel rang), surcouchables
• Aucun profil n'est calculé pour les cd_ref qui n'ont pas de paramètres définis
• Des fonctions permettent de "checker" les différentes informations

Il reste quelques points à discuter avant de faire une PR :

• Dans quel schéma ranger ces profils ? (qui reposent sur un ensemble tables, VM, vues et fonctions). Actuellement créé dans gn_commons pour le développement, @camillemonchicourt a évoqué la possibilité d'un schéma dédié gn_profiles
• Reprendre le travail de Gil évoqué ci-dessous et le supprimer s'il s'agit bien des mêmes informations (je vais regarder ça rapidement)
• Voir si les performances peuvent être améliorées

Les prochaines étapes de mon coté sont :

• Valider ce fonctionnement pour lancer une prestation visant à compléter le module validation (avoir une checklist des informations qui collent, ou non, au profil du taxon en question)
• Développer une fonction qui permet, avec un lieu et une date, et prédire les espèces potentiellement à relever sur le site en question
• Et pour le pôle invertébrés en particulier, développer une fonction qui valide automatiquement les données qui répondent à toutes les variables de leur profil.

Je n'ai pas encore fait de PR mais je partage ici le fichier avec le script tel qu'il est proposé actuellement.
doc_profils.txt
script_profils_final.txt

[camillemonchicourt]

OK merci. Quelques remarques.

• A voir, si on ajoute ça dans gn_commons (qui commence à être bien chargé) ou si on fait un schéma dédié pour regrouper ça dans un bloc plus lisible, avec un schéma gn_profile. C'est subjectif mais j'aurai tendance à y dédier un schéma gn_profile pour bien grouper tout le bloc (tables, fonctions, vues matérialisées)
• Si il y a des fonctions ajoutées dans le schéma taxonomie, c'est à faire au niveau de TaxHub
• Petit détail de vocabulaire, je ne trouve pas forcément clair le is_valid dans les fonctions. Par exemple gn_commons.check_profile_distribution_is_valid laisse penser que cela vérifie si le profil de distribution est valide, et non pas si l'occurrence est incluse dedans. Du coup virer le is_valid me semble plus clair. Du coup ça donnerait gn_commons.check_profile_distribution.

[DonovanMaillard]

Une petite correction sur le script transmis ci-dessus :

• Correction de la prise en compte ou non du stade de vie, qui renvoyait plusieurs lignes au lieu d'une dans la cor_taxa_phenology (on avait une ligne par stade de vie, même si le stade était NULL sur chacune des lignes)
• Correction identique pour la fonction check profile phenology

Un ajout également : actuellement, les données à cheval sur 2 années (31/12->2/01) ne sont pas comptabilisées dans la phénologie, j'ai une solution en tête à tester pour ce point là.

[DonovanMaillard]

Concernant la proposition de Camille de créer un schéma gn_profiles (avec un s plutôt), ca a d'autant plus de sens si on part dans l'idée d'enrichir les profils à termes en tenant compte par exemple des habitats, si on veut à terme des fonctions de validation automatique basées sur ces profils, ou des fonctions de prédiction d'espèces basées sur ces profils.

Pour le nom des fonctions, pas forcément de nom idéal mais on peut supprimer les "is_valid" qui allongent le nom pour une pertinence en effet discutable.

Une incohérence dans les paramétrages relevée à l'instant :

Les calculs de l'aire d'occurrences est basée sur le geom_local, et le paramètre de la précision spatiale est spatial_precision_m. L'unité du mètre n'est vraie que si on est en lambert 93. Si la geom locale est le wgs84, les tampons seront calculés non plus en mètres mais en degrés.

Je vais le rectifier dans le nom du paramètre.

[DonovanMaillard]

PR #941

[camillemonchicourt]

Il y a quelques semaines, une session de développement a été organisée sur le sujet avec @DonovanMaillard, @TheoLechemia, @lepontois, @jpm-cbna et @Adrien-Pajot.

Le travail a été découpé en plusieurs tickets :

• BDD : [Profil taxon] - Implémenter le SQL #1103
• Backend : [Profil taxon] Backend #1104
• Frontend : [Profil taxon] Frontend #1105

Documentation et aperçu des développements actuels : https://github.com/PnX-SI/GeoNature/blob/e76eecf307b9947763c95b3898d6c23a63d4f13d/docs/admin-manual.rst#profils-de-taxons

La BDD est stabilisée, reste à finaliser quelques points sur le backend et frontend.

[TheoLechemia]

Le travail en cours a été finalisé dans la branche https://github.com/PnX-SI/GeoNature/tree/feat/profil-taxon

Il implémente trois nouvelles fonctionnalités:

• Avertissement lorsqu'une donnée ne correspond pas au profil lors de la saisie Occtax.
  

• Contextualisation d'une observation vis à vis du profil, accèssible depuis la fiche info de la synthese (partagé entre le module synthese et validation)

• Fiche taxon présentant le profil (accessible depuis la fiche info synthese et des avertissement Occtax). Celle-ci est largement améliorable. On pourrait mettre les observations de l'espèce et d'autres infos (s'inspirer de l'atlas !)
  

Côté backend, trois nouvelles routes:

• GET : gn_profile/valid_profile/<cd_ref> qui donne les informations sur le profil au format geoJson (aire de répartition, nombre d'observation valide, plage d'altitude, première et dernière observation)

• GET : gn_profile/consistancy_data/<id_synthese> qui donne un score indicatif de "validité" d'une observation (de 0 à 3) vis à vis du profil, ainsi que le détails de chaque critère sous forme de booléen:

{
  "score": <int>,
  "valid_distribution": <boolean>,
  "valid_phenology": <boolean>,
  "valid_altitude": <boolean>
}

• POST : gn_profile/valid_profile/<cd_ref>: qui attend en entrée les informations sur l'observation qu'on veut vérifier :

{
      "cd_ref": <int>,
      "date_min": <date>,
      "date_max": <date>,
      "altitude_min": <int>,
      "altitude_max": <int>,
      "geom": <geojson>,
      "life_stages": <int[]>
  }

La route renvoie les informations suivantes:

{
        "valid_distribution": <boolean>,
        "valid_altitude":  <boolean>,
        "valid_phenology":  <boolean>,
        "valid_life_stage":  <boolean>,
        "life_stage_accepted": <int[]>,
        "errors": [],
        "profil": <Profil>,
        "check_life_stage": <boolean>
    }

[DonovanMaillard]

Un grand merci Théo pour la reprise et finalisation de ce travail! :)

[camillemonchicourt]

Profils de taxons intégrés dans la 2.9.0