Sensibilité - Automatiser le calcul

[camillemonchicourt]

Un travail de modélisation et de base de données a été réalisé pour calculer la sensibilité d'une observation et a été intégré dans la version 2.1.0 de GeoNature (#284).

Il faut désormais mettre en place une automatisation du calcul, sous forme de trigger ou de cron.

[jpanijel]

Je ne sais pas si cela te sera utile, voici la note de spécification pour le calcul de sensibilité dans GINCO.
note_application_regles_sensibilite_07-12-2018.pdf

[camillemonchicourt]

Les triggers ligne par ligne risquent de trop alourdir, surtout quand on importe un gros volume de données.
Il faut qu'on puisse lancer les calculs de suite après insertion d'une donnée pour pas avoir un delta, donc un cron quotidien ne suffit pas.

Du coup, on avait évoqué une fonction applicative, que l'on peut lancer après un import (avec le module Import), après une saisie ou modification dans un module de saisie (Occtax, Monitoring....). Mais comment la centraliser ça pour qu'elle agisse depuis toutes les sources ? Surtout qu'au final c'est surtout une insertion/modification dans la Synthèse qui est importante pour lancer les calculs.
Et comment lancer la fonction si jamais on fait des insertion/modification directement dans la BDD... ?

Une solution intermédiaire pourrait être les triggers mais au niveau statement, évoqués par @jpm-cbna dans #997 (comment)
Voir en complément - https://blog-postgresql.verite.pro/2017/09/01/triggers-postgresql-10.html

Cela imposera d'être en PostgreSQL version 10 minimum.

[TheoLechemia]

On privilégie la piste des triggers statement et donc de passer sur PostgreSQL 10 minimum.

• Calcul initial sur les observations des taxons qui ont une règle (dans synthèse uniquement) + valeur max pour les obs des taxons qui n'ont pas de règle. Attention à ne pas modifier synthese.meta_update_date
• Trigger statement sur insert/update dans la synthèse + Calcul du diffusion_level lié à la sensibilité si il n'a pas déjà de valeur inférieure à celle calculée (vérifier les valeurs par défaut)
• Trigger statement sur cor_sensitivity_synthese vers synthèse (uniquement pour la sensibilité manuelle qui surcouche la sensibilité calculée)
• Trigger ROW sur la table des règles qui relance que sur les observations du taxon concerné par la modification de règle (ajout, suppression, activation)
• Cron pour vérifier les observations dont la sensibilité périodique a expiré.

[TheoLechemia]

Ce qui a été fait:

• Insertion dans la synthese -> update id_nomenclature_sensitivity & id_nomenclature_diffusion_level (si pas NULL)
• Update de cd_nom, the_geom_local, the_geom_4326, date_min, id_nomenclature_bio_status -> update id_nomenclature_sensitivity & id_nomenclature_diffusion_level (si pas NULL)
• Insertion dans gn_sensitivity.cor_sensitivity_synthese -> update de id_nomenclature_sensitivity
  Le problème est pour la MAJ de id_nomenclature_diffusion_level quand id_nomenclature_sensitivity est MAJ manuellement.
  Mettre un trigger d'update uniquement sur la colonne id_nomenclature_sensitivity fait travailler deux fois le 1er trigger d'insertion dans la synthese (car il fait lui même un update).
  Je me pose la question de la pertinence de pouvoir éditer manuellement la sensibilité (alors c'est une information factuelle calculée). Est-ce que ce serait pas le "diffusion_level" qui serait pas interessant de pouvoir éditer manuellement ?

[camillemonchicourt]

Oui en effet c'est plutôt la diffusion qui peut être subjective au niveau d'une observation, pas sa sensibilité.

[amandine-sahl]

Le soucis, c'est que certaines règles de sensibilité peuvent être dur à appliquer automatiquement et ne sont pas liées à des champs d'occtax (exemple : que les places de champs, ...).

[jpanijel]

Dans l'esprit de la méthodologie le fonctionnement établi est assez simple : il faut calculer et appliquer par défaut le niveau de sensibilité le plus élevé (celui de la règle de sensibilité) selon les critères pouvant automatiquement être calculés.
S'il y a des subtilités à prendre en compte alors la sensibilité manuelle peut intervenir, mais c'est uniquement pour baisser la sensibilité calculée automatiquement. Donc le principe que nous avons établi dans GINCO est la suivante : si le champ remarque de la liste de sensibilité (qui précise les condition d'application de la règle) est rempli, alors on applique la règle et on met un flag sur la donnée > sensibilité manuelle requise.
Concernant la sensibilité manuelle, le principe de réalité fait que personne ne reprend à la main les données donc il faut relativiser. Il y a déjà assez à faire avec la validation scientifique.

[camillemonchicourt]

Oui, dans tous les cas, si on fait de la sensibilité manuelle, ce ne sera pas directement stocké dans la table Synthèse (dont le contenu doit être calculable), mais dans une table dédiée gn_sensitivity.cor_sensitivity_synthese.
Donc pas de boucle à priori.

Mais pour l'instant on garde cette table mais on ne l'utilise pas car on met de côté la sensibilité manuelle.
C'est plutôt le niveau de diffusion que l'on peut éventuellement surcoucher.

[camillemonchicourt]

En plus du trigger, il faudra bien faire la mise à jour sur toutes les données existantes dans le SQL d'update.

[camillemonchicourt]

Les triggers de calcul de la sensibilité basée sur les règles de sensibilité du SINP dans la table dédiée ont été intégrées dans la version 2.6.0 (https://github.com/PnX-SI/GeoNature/blob/develop/data/core/synthese.sql#L587-L656).
Ils sont encore améliorables pour gérer les cas où le niveau de diffusion (et éventuellement le niveau de sensibilité à la marge) sont renseignés par ailleurs.