Floutage des observations sur le niveau de sensibilité et de diffusion

[jpm-cbna]

La vue syntheseff se charge de flouter les données issue de la synthese vis à vis du niveau de diffusion. Il faudrait aussi le faire vis à vis du niveau de sensibilité.

Au passage, il est nécessaire d'améliorer les performance de cette vue syntheseff car elle ne fonctionne pas avec plusieurs millions d'observation dans la table synthese.

Le problème de performance de la vue syntheseff vient de la sous-requête CTE areas (CTE = Common Table Expressions). En la remplaçant par une vue matérialisée atlas.vm_cor_synthese_area, cela permet de résoudre le problème de performances et de flouter les observations correctement vis à vis du niveau de diffusion et de la sensibilité.

Il est aussi nécessaire d'ajouter un option fetch_size au FDW pour pouvoir augmenter la valeur 100 par défaut. Avec plusieurs millions d'observations dans la synthèse, cette valeur doit pouvoir être passée à 100 000 (voir 1 000 000).

[camillemonchicourt]

Dans ce cas là, il faut peut-être revoir la logique car cette vue est la porte d'entrée sur laquelle s'appuie des VM, mais pas l'inverse.

[jpm-cbna]

La VM sur laquelle s'appuie la vue syntheseff est à part. Seule syntheseff s'en servira.
Je ne voie pas d'autres alternatives.

[camillemonchicourt]

Je ne crois pas que cela soit souhaitable que la vue syntheseff se base sur une VM, par exemple si l'atlas ne se base pas sur une BDD GeoNature. Mais je n'ai plus tout en tête.
Une autre solution serait de calculer le floutage après la vue syntheseff plutôt qu'avant.

Mais je suis très embrouillé sur ce sujet complexe, donc je n'ai pas d'avis clair ni tranché sur le sujet.

Une solution plus complète avait été initiée ici : #117

[TheoLechemia]

Mouais, comme je disais à @jpm-cbna , ça devient vraiment compliqué à maintenir cette compatibilité GN et pas GN.
On se traîne des lourdeurs alors qu'on a toutes les tables nécessaires dans GeoNature pour que les VM se calculent rapidement (cor_area_synthese).

Dans cette PR https://github.com/PnX-SI/GeoNature-atlas/pull/358/files , j'avais initié un travail similaire pour que les vm_observations et vm_observations_maille ne passe plus par syntheseff, mais interroge directement synthese et une vm_cor_area_synthese créé au préalable. Mais du coup ça veut dire maintenir deux mécanisme de calcul des vm, un GN et un hors GN.
A mon avis il vaut mieux assumer d'avoir deux mécanismes différents et de les maintenir plutôt que rester dans ce statut quo qui dégrade les deux.

[jpm-cbna]

Je ne crois pas que cela soit souhaitable que la vue syntheseff se base sur une VM, par exemple si l'atlas ne se base pas sur une BDD GeoNature. Mais je n'ai plus tout en tête.

La solution que je propose maintien toujours la vue syntheseff ce qui permet de n'avoir rien à changer à la solution d'utilisation de l'Atlas hors GeoNature.

Par ailleurs, cela ne modifie rien aussi à la solution d'utilisation de l'Atlas avec GeoNature. Hormis 2 choses :

• l'ajout du champ "sensitivity" à la vm_observations sur le principe du champ "diffusion_level" déjà présent. Mais c'est d'ailleurs peut être inutile (?).
• l'ajout de la VM vm_cor_area_synthese à la fonction qui rafraîchie les vues.

[camillemonchicourt]

OK je n'y vois pas assez clair sur le sujet pour avoir un avis éclairé.