PnX-SI / GeoNature-atlas

Application WEB permettant de générer des fiches espèces publiques à partir d'observations faune/flore
GNU General Public License v3.0
44 stars 48 forks source link

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

Open jpm-cbna opened 2 years ago

jpm-cbna commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

camillemonchicourt commented 2 years ago

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 : https://github.com/PnX-SI/GeoNature-atlas/issues/117

TheoLechemia commented 2 years ago

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 commented 2 years ago

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 :

camillemonchicourt commented 2 years ago

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