Open jpm-cbna opened 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.
La VM sur laquelle s'appuie la vue syntheseff
est à part. Seule syntheseff
s'en servira.
Je ne voie pas d'autres alternatives.
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
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.
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 :
sensitivity
" à la vm_observations
sur le principe du champ "diffusion_level
" déjà présent. Mais c'est d'ailleurs peut être inutile (?).vm_cor_area_synthese
à la fonction qui rafraîchie les vues.OK je n'y vois pas assez clair sur le sujet pour avoir un avis éclairé.
La vue
syntheseff
se charge de flouter les données issue de lasynthese
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 tablesynthese
.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éeatlas.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).