Sensibilité : précision sur la logique d’application des règles

[bouttier]

Une règle de sensibilité est caractérisée par un niveau de sensibilité, et des conditions d’application : période de validité (e.g. de février à mai), durée (e.g. durant 5 ans), zonages (e.g. région PACA), critères (statut bio et/ou comportement).

Lorsque plusieurs règles s’appliquent, on retient le niveau de sensibilité le plus élevé. En ce sens, les règles sont additives. Une observation est sensible si une règle s’applique OU une autre s’applique.

Une règle s’applique si toutes les conditions d’application sont remplies, i.e. les conditions d’applications sont exclusives : une règle s’applique si l’observation est en PACA ET a moins de 5 ans. Si une règle n’a pas de période de validité, elle s’applique toute l’année. De même, si elle n’a pas de zonage, elle s’applique partout, etc. sous réserve que les autres conditions sont bien toutes remplies.

Une règle peut être associée à plusieurs zonages, par exemple PACA et AuRA. Ces zonages sont additifs, i.e. la règle s’applique si l’obs est en PACA OU en AuRA (sous réserve des autres conditions). De même, une règle peut être associé à plusieurs critères, par exemple statut bio NSP et statut bio Reproduction. Dans ce cas, la règle s’applique si l’obs a un statut bio NSP OU si elle a un statut bio Reproduction.

Actuellement, les critères sont mélangés tous types confondus (statut bio et comportement). Si une règle est associée à statut bio NSP et comportement Estivage, la règle s’applique si l’obs a un statut bio NSP OU un comportement Estivage. Il n’est en l’état pas possible de créer une règle devant s’appliquer si l’obs a un statut bio végétatif ET un comportement Erratique. La fonction gn_sensitivity.get_id_nomenclature_sensitivity pourrait évoluer ainsi :

  SELECT INTO sensitivity r.id_nomenclature_sensitivity
  FROM gn_sensitivity.t_sensitivity_rules_cd_ref r
  JOIN ref_nomenclatures.t_nomenclatures n ON n.id_nomenclature = r.id_nomenclature_sensitivity
  LEFT OUTER JOIN gn_sensitivity.cor_sensitivity_area USING(id_sensitivity)
  LEFT OUTER JOIN ref_geo.l_areas a USING(id_area)
- LEFT OUTER JOIN gn_sensitivity.cor_sensitivity_criteria c USING(id_sensitivity)
+ LEFT OUTER JOIN (
+    gn_sensitivity.cor_sensitivity_criteria c1 JOIN ref_nomenclatures.bib_nomenclatures_types t1 ON c1.id_type = t1.id_type AND t1.mnemonique = 'STATUS_BIO'
+ ) USING(id_sensitivity)
+ LEFT OUTER JOIN (
+    gn_sensitivity.cor_sensitivity_criteria c2 JOIN ref_nomenclatures.bib_nomenclatures_types t2 ON c2.id_type = t2.id_type AND t2.mnemonique = 'OCC_COMPORTEMENT'
+ ) USING(id_sensitivity)
  WHERE
      ( -- taxon
          my_cd_ref = r.cd_ref
      ) AND ( -- zone géographique de validité
          a.geom IS NULL -- pas de restriction géographique à la validité de la règle
          OR
          st_intersects(my_geom, a.geom)
      ) AND ( -- période de validité
          to_char(my_date_obs, 'MMDD') between to_char(r.date_min, 'MMDD') and to_char(r.date_max, 'MMDD')
      ) AND ( -- durée de validité
          (date_part('year', CURRENT_TIMESTAMP) - r.sensitivity_duration) <= date_part('year', my_date_obs)
-     ) AND ( -- critère
-         c.id_criteria IS NULL -- règle sans restriction de critère
-         OR
-         -- Note: no need to check criteria type, as we use id_nomenclature which can not conflict
-         c.id_criteria IN (SELECT value::int FROM jsonb_each_text(my_criterias))
+     ) AND ( -- critère status biologique
+         c1.id_criteria IS NULL -- règle sans restriction de critère status biologique
+         OR
+         c1.id_criteria IN (SELECT value::int FROM jsonb_each_text(my_criterias))
+     ) AND ( -- critère comportementale
+         c2.id_criteria IS NULL -- règle sans restriction de critère comportement
+         OR
+         c2.id_criteria IN (SELECT value::int FROM jsonb_each_text(my_criterias))
+     )
+ ORDER BY n.cd_nomenclature DESC;

Mais il y a peut-être une meilleur approche, celle-ci ayant pour inconvénient de restreindre cette fonction aux critères statut bio / comportement alors que la fonction était précédemment générique.

Autre commentaires :

• Bien que la fonction est (actuellement) générique pour tous types de critères, pour utiliser d’autres critères que statut bio ou comportement, il serait nécessaire de faire évoluer les triggers gn_synthese.fct_tri_calculate_sensitivity_on_each_statement et gn_synthese.fct_tri_update_sensitivity_on_each_row afin de fournir ces autres critères à get_id_nomenclature_sensitivity.
• Le script d’insertion des règles de sensibilités rajoute, dès lorsqu’un critère statut bio (resp. comportement) est présent, les nomenclatures statut bio "Inconnu", "Non renseigné", "Non Déterminé" (resp. nomenclatures comportement "NSP", "1") aux critères d’application de la règle par principe de précaution.
• Si une obs a pour statut bio NULL, toute règle de sensibilité ayant un critère statut bio se n’appliquera pas. Mais normalement aucune obs n’a un id nomenclature NULL en raison d’une valeur par défaut en base. Ces colonnes n’ont toutefois pas de contraintes NOT NULL, il reste donc théoriquement possible d’insérer des valeurs NULL manuellement. L’activation de la contrainte NOT NULL est à envisager.