[Synthese] - the_geom_* VS id_area_attachment

[jbrieuclp]

Salut, Je veux faire suite à #867 et mieux gérer la duplication des géométries de l_areas dans la synthèse. Si je prend l'exemple de ma BD, j'ai actuellement 1 530 902 données en synthèse dont 181 265 possédant une info de id_area_attachement.

Ma table synthèse pèse 9 196MB au total. Là-dedans le stockage des géométries dans le champ the_geom_4326 de mes 181 265 données avec id_area_attachment prend 5 824MB. Pour les 1 349 637 autres données localisées au point, ligne ou polygone le stockage des géométries prend 58MB. C'est donc beaucoup trop pour des géométries qui sont déjà stockées dans une table de référence.

Du coup que pensez-vous de ces propositions :

• ajouter une contrainte sur la table synthèse pour avoir soit une géométrie (the_geom_4326 IS NOT NULL AND id_area_attachment IS NULL) ou soit un rattachement à l_areas (the_geom_4326 IS NULL AND id_area_attachment IS NOT NULL)
• Modifier le triggers tri_update_cor_area_synthese pour qu'il prenne en compte les données rattachées à l_areas
• Modifier la vue gn_synthese.v_synthese_for_web_app pour intégrer une jointure en LEFT JOIN avec l_areas et servir les différents champs géométriques en COALESCE(synthese.the_geom_4326, l_areas.geom) (en prenant soin de faire attention aux projections)
• idem pour la vue gn_synthese.v_synthese_for_export
• idem pour la vue gn_commons.v_synthese_validation_forwebapp

Côté applicatif j'ai trouvé une utilisation de la class Synthese(DB.Model) au niveau du fichier routes.py du module gn_meta pour la fonction get_acquisition_framework_bbox et au niveau du fichier route.py du module gn_synthese pour la fonction get_bbox (URL "/observations_bbox") Pour ces 2 cas je pense qu'il est envisageable d'aller taper sur le Model VSyntheseForWebApp de la vue gn_synthese.v_synthese_for_web_app ?

Je vais faire ces modifs sur ma BD et je pourrais proposer un script de modification. Après, est-ce qu'il peut y avoir des effets de bord sur des cas non listés au-dessus, dans d'autres modules, qui serait à prendre en compte ?

[camillemonchicourt]

C'est sur que si on en a beaucoup cela devient assez contre productif de dupliquer la géométrie des zonages. La question que l'on peut se poser est pourquoi il y a tant de données non précises et toute la question de dégrader les données avant de les partager.

Dans tous les cas, si l'on fait cela, ça rendra l'usage de la synthèse plus compliqué et un peu moins lisible car parfois on a la géométrie directement dans la table et parfois il faudra aller la chercher dans une autre.

Quand ils utilisent directement la BDD les utilisateurs ont l'habitude de requêtes directement dans la Synthèse et là il faudra qu'ils fassent attention à ne pas oublier des géométries.

Si on fait cela, je pense qu'il faudra proposer une vue qui remet justement à plat la synthèse avec une géométrie pour chaque ligne, pour en faciliter l'usage.

Il y aura aussi à répercuter ce changement dans le module Export qui fournit une vue par défaut basée sur la synthèse.

[TheoLechemia]

Je ne vois pas d'effet de bord, si ce n'est d'un peu compliqué l'affichage des données floutées dans la synthese. Mais je suis d'accord sur le fond pour la cohérence de la BDD

[camillemonchicourt]

Oui les éventuels effets de bord ne sont pas dans Synthèse où on maîtrise les choses, mais plutôt pour ceux qui utiliseraient la Synthèse de leur GN dans d'autres outils (Lizmap, Redash, PGAdmin...) qui n'auront pas toutes les géométries si ils font un SELECT * FROM gn_synthese.synthese.

[jbrieuclp]

Exact il y a aussi les vues par défaut du module d'export !

[lpojgc]

Je déterre ce ticket : après recherches, outre quelques échanges sur le ticket ci-dessus, j'ai l'impression qu'il n'y a pas eu d'avancés. Est-ce qu'il est envisagé de réellement utiliser ce champ pour optimiser le stockage en BDD ou pas ? De mon côté j'y verrais de gros avantages... Merci d'avance pour les (éventuelles) nouvelles.

[jbrieuclp]

Dans la requête qui récupère les données pour le module validation il y a le critère the_geom_4326 IS NOT NULL qui n'est actuellement pas débrayable via paramétrage... Il y a peut-être d'autres modules ou c'est le même topo.

https://github.com/PnX-SI/GeoNature/blob/0e862b2d9577bc408824a21e78effcf038e28b40/contrib/gn_module_validation/backend/gn_module_validation/blueprint.py#L138

2851

[gildeluermoz]

D'une manière générale je pense qu'il est indiscutable que la duplication des geom est un vrai soucis. Les chiffres que donnent @jbrieuclp sont très parlants. En terme de perf, c'est potentiellement un vrai pb aussi.

Il y a plusieurs pistes avec avantages et inconvénients évoqués dans cette issue mais il me semble qu'il y a une piste qui n'est pas abordée : celle d'une table des geométries, la plus transversale possible. Dans l'absolu et de manière totalement théorique, qq chose comme gn_commons.all_geoms. Ensuite, dans tous les autres schémas et tables pr_occtax.t_releves_occtax, gn_synthese.synthese, et pourquoi pas ref_geo.l_areas, une simple colonne id_geom en clé étrangère de gn_commons.all_geoms.id_geom. Voir si besoin de faire des types de geom pour filtrer et améliorer certaines jointures

Une solution intermédiaire et plus simple consisterait à adopter cette approche uniquement en synthèse car c'est principalement la synthèse qui génère ces duplications ; avec une table gn_syntese.t_geoms

C'est une approche très conceptuelle et ce n'est pas moi qui vais faire les dev mais ça ouvre beaucoup d'avantages :

• réduction potentiellement importantes de la taille de la base
• amélioration des perfs (peut-être pas toujours à cause de la jointure systématique à faire)
• généricité du modèle et du principe
• gestion unique de la localisation de la geométrie des observations que ce soit un géoréférencement ou un rattachement
• non duplication en synthèse des geoms de relevés occtax comportant de nombreuses occurences et/ou counting
• non duplication des geoms de monitorings en synthèse (gros gains potentiels à ce niveau si monitoring produit beaucoup)
• possibilité éventuelle dans un second temps de proposer le rattachement de certaines obs d'occtax à des geom existantes lorsque le pointage est proche.
• possibilité d'ajouter une option de création de la geom par rattachement dans le module d'import sur des données historiques faites par rattachement (communes par ex, c'est fréquent)
• possibilité de nommer optionnellement certaines localisation ('mon jardin', 'mirador bidule', 'point d'eau truc', 'mare du bourg', etc...) pour y refaire/rattacher des obs hors protocole avec occtax sans avoir à construire un sous-module de monitoring et avoir une pseudo-entrée par lieu/site dans occtax.

Coté inconvénients, il y en a aussi

• jointure systématique à écrire mais on l'a déjà pour toutes les nomenclatures et pour les observateurs et la solution de faire une VM consolidée de synthèse reste un contournement possible
• beaucoup de dev, modif de modèles et de vues à reprendre
• migration potentiellement délicate de la base
• la gestion des doublons potentiels des geoms ajoute des difficultés dans la conception frontend

En tout cas, cette approche me semble moins casse-gueule que de gérer les 2 cas de géoréférencement ou rattachement pour les geoms d'une même table mais situés selon les cas dans la table ou hors de la table.

Ca me semble être une grosse grosse évolution. Peut-être dans une V3 ?