Calcul des couleurs par taxon

[TheoLechemia]

Le travail du calcul des "couleurs" pour chaque taxon dans les "unités" géographiques a été amorcé ici: 444af26

Récapitulatif:

• la table cor_area_taxon est situé dans la synthese (elle était dans le schéma contactfaune dans GN1)
• elle est remplie par un trigger sur la table gn_synthese.cor_area_synthese (table des intersections de toutes les aires présente dans le ref_geo avec les observations de la synthese), plutôt que sur la synthese directement, pour éviter de faire deux fois le calcul des intersections
• il est nécessaire de rajouter un champs "cd_nom" dans la table gn_synthese.cor_area_synthese si on veux retrouver les enregistrement de la table gn_synthese.cor_area_taxon au moment du trigger sur gn_synthese.cor_area_synthese``
• la table gn_synthese.cor_area_taxon contient donc les intersections avec toutes les entités du ref_geo. Chaque module qui veux utiliser le mécanisme des couleur pourra se faire une vue et filtrer sur le type d'aire, sur les taxons etc...
• Le calcul de la couleur n'est plus basé sur l'année en cour mais sur un nombre de jour à partir de la date du jour (j'ai mis 365 jours)
• Le mécanisme de recalcule des couleurs n'est pas encore mis en place. On pourra le faire via un cron toute les nuit, ou toute les semaines...

[TheoLechemia]

Quelques modifications:

• on ne met pas le cd_nom dans la table cor_area_synthese
• le on delete cascade entre synthese et cor_area_taxon a été supprimé car il ne permettait pas de récupérer les aires intersectées pour le recalcule des couleurs. Ce mécanisme de suppression en cascade est reproduit par un trigger déclenché à la suppression d'une ligne en synthese qui vient (re)calculer les couleurs des taxons, puis seulement ensuite supprimer les enregistrements dans cor_area_synthese
• un trigger insert/update est déclenché sur la table cor_area_synthese pour le calcul des couleurs
• un troisième trigger est déclenché à la modification de la colonne cd_nom de la synthese pour recalcule des couleurs

b9558aa

[camillemonchicourt]

La couleur des taxons dans chaque unité géographique n'est plus un champs en dur dans la table gn_synthese.cor_area_taxon, calculé par CRON, mais désormais une information calculée dans la vue gn_synthese.v_color_taxon_area

Voir 1a93991

[camillemonchicourt]

En fait, je n'aurai pas stocké des valeurs de couleurs mais plutôt des valeurs réelles (Jamais observé, Observé depuis 1 an, ... ou des nombres de jours). La couleur étant un choix de représentation d'une valeur au niveau applicatif.

[jbdesbas]

Bonjour,
La table cor_area_taxon et la vue v_color_taxon_area ont-elle une utilité (ou une utilité future) dans l'application GeoNature ? En faisant des recherches dans le code il ne semble pas que ça doit le cas.
J'ai l'impression que le trigger sur le synthese pour alimenter cette table est assez gourmand et pourrait être désactivé si on utilise pas cor_area_taxon

[camillemonchicourt]

Pour le moment ce n'est utilisé que par Occtax-mobile : PnX-SI/gn_mobile_occtax#5
Le territoire est découpé en polygones (sur la base d'une couche au choix dans le ref_geo) et pour chaque zone on calcule si les espèces connues sur le territoire ont déjà été observées dans le polygone, observé mais il y a plus d'un ou il y a moins d'un an. Cela permet d'orienter les prospections et d'indiquer à un utilisateur quand il est dans un polygone, l'état des données dans celui-ci. Avec en plus le nombre d'observations du taxon dans le polygone et la date de dernière observation. Aperçu : PnX-SI/gn_mobile_occtax#23 (comment)

Ce n'est pas implémenté dans la version web d'Occtax car moins utile, même si c'était le cas dans GeoNature v1. On pourrait le faire ou mettre un indication à la saisie pour que l'utilisateur sache si sa donnée est nouvelle, si elle met à jour une donnée ancienne ou uniquement confirme une donnée récente.
On pourrait aussi utiliser ces données dans le Dashboard pour donner un aperçu des connaissances et des priorités de taxons.

La liste des taxons pour lesquels le calcul est réalisé se base sur la liste des espèces présentes dans la Synthèse.

En effet pour ceux qui n'utilisent pas Occtax-mobile ou ne souhaitent pas disposer du mécanisme des taxons par couleur par polygone, on peut imaginer désactiver le trigger. Ou sinon relancer le calcul que toutes les nuits avec un cron ou un mécanisme du genre.

[jbrieuclp]

Si c'est juste une info d'aide a la saisie une vue matérialisée réactualisée par CRON serait plus judicieuse. Quand on réalise des imports de données dans la synthèse ce trigger plus celui qui renseigne cor_area_synthese font que les temps de calculs sont super long.
Pareil, je pense qu'il faudrait revoir l'algo du trigger pour cor_area_synthese. D'ailleurs trigger ou CRON ?

[jbdesbas]

Merci pour ces précisions, je n'utilise pas (encore) occtax mobile, mais comme @jbrieuclp je partirai aussi pour un CRON pour cor_area_taxon et cor_area_synthese

[camillemonchicourt]

On s'est posé ces questions. Le problème du CRON est que l'info n'est pas instantanée. Du coup quand un utilisateur renvoie ses saisies, cela alimente la synthèse et donc met à jour les couleurs directement avec le trigger et l'utilisateur repart avec les infos mises à jour.
Si c'est un cron alors il y a un décalage dans les données.

[jbrieuclp]

Oui, mais est-ce que pour ce type d'info/de donnée la synchronisation immédiate est impérative. D'après ce que tu expliquais du rôle de cor_area_taxon, je ne pense pas. Pour cor_area_synthese, la question se pose d'avantage. Après le cron peut être exécuté toutes les X heures plutôt que chaque nuit pour réduire l'impact du décalage.
L'idéal serait de recalculer ces infos à chaque session d'ajout terminée. Ça correspondrait à l'ajout de plusieurs données et non à chaque ligne ajoutée comme c'est actuellement le cas. Seulement est-ce qu'il y a un déclencheur sur ce type de truc de fin de session ?

[DonovanMaillard]

Pour la cor area taxon et les couleurs, un cron n'est pas très problématique à mon sens. En revanche sur la cor area synthèse je trouverais ca bien plus embêtant, de saisir une donnée, d'aller en synthèse en faisant une recherche par commune par exemple, et de ne pas la retrouver... pour une utilisateur c'est pas très lisible, personnellement je resterais sur le trigger pour cette table là en particulier.

La couleur à la saisie a sans doute moins besoin d'être instantanée

[camillemonchicourt]

En effet faire les traitements sous forme de CRON, même toutes les heures, peut créer des incohérences quand on fait une recherche dans le Synthèse après une saisie ou un gros import.
C'est le cas pour le calcul des zonages, mais aussi pour la sensibilité qui devra bientôt être calculée de la même manière dès l'intégration dans la synthèse, au risque de diffuser des données sensibles le temps qu'elle soit définie.
Pour les couleurs des taxons, si un utilisateur ajoute des données, il peut ne pas comprendre que les couleurs des taxons n'aient pas changé si il fait une nouvelle saisie dans la foulée.
Donc un calcul décalé est peu satisfaisant pour cela aussi.

Néanmoins un calcul ligne par ligne à chaque insertion pose des gros problèmes de performances, et on voit qu'il y a encore des calculs à ajouter (sensibilité notamment). Cela pose des questions importantes pour le module Import (https://github.com/PnX-SI/gn_module_import) qui est sortie en version 1.0.0 il y a quelques semaines mais dont les développements actuels travaillent sur le volet Performances notamment.

Un déclenchement des calculs à la fin des insertions et non pas ligne par ligne serait idéal, mais je ne sais ce qu'il est possible de faire ?
Sachant qu'on veut pouvoir insérer des données directement dans la BDD, ce qui nous a poussé à intégrer les mécanismes au niveau BDD (triggers) et non pas au niveau applicatif.

[jbrieuclp]

A tester, mais il est p'tet possible de déclencher une fonction de mise à jour de ces différentes tables de données par trigger en fin de transaction avec les paramètres DEFERRABLE et/ou INITIALLY DEFERRED : https://www.postgresql.org/docs/12/sql-createtrigger.html

[camillemonchicourt]

Ici un aperçu de ce que ça donne dans Occtax-mobile, selon sa zone de localisation, cela affiche pour chaque espèce si elle a déjà été vue dans la zone, depuis quand, combien de fois et la dernière date d'observation :

[camillemonchicourt]

Intégré dans la version 2.1.0.
Revue pour ne plus avoir de trigger dans la 2.6.0.