Validation impossible de données sans géométrie

[jbrieuclp]

Validation impossible de données sans géométrie

[camillemonchicourt]

On considère que toute donnée dans la Synthèse doit avoir une géométrie et que c'est obligatoire.
On en avait un peu discuté sur #1476

Intéressant si tout fonctionne bien en adaptant la vue, mais on ne peut garantir ce fonctionnement.

Mais pourquoi il y a ce critère dans le module Validation, je ne sais pas de mon côté. 🤔

[camillemonchicourt]

De mémoire, ce critère a été mis en place car les données sans géométrie posent soucis dans le module Validation et dans le module Synthèse.
Bon, normalement ce cas ne peut pas se produire car une donnée dans la Synthèse doit forcément avoir une géométrie.

Donc la contrainte a du être ajoutée dans le module VALIDATION pour vérifier ce cas qui a du se produire je sais pas quand ni comment, dans ce commit : 1f31e7e

Est-ce qu'on peut enlever cette contrainte sans perturber autre chose ou les performances, je ne sais pas.
Pourquoi il y a cette contrainte dans le module Validation mais pas le module Synthèse, je ne sais pas.

Dans tous les cas, ça reste actuellement un cas non supporté de GeoNature que de ne pas avoir de géométrie des observations de la Synthèse.

[jbrieuclp]

La synthèse consulte les vues gn_synthese.v_synthese_for_web_app et gn_synthese.v_synthese_for_export. De fait ces vues peuvent intégrer la jointure vers la table ref_geo.l_areas afin de récupérer la géométrie référencée via le champ id_area_attachment de la synthèse. Dans ce cas toutes les données de la synthèse se retrouvent avec une géométrie, soit par géoréférencement soit par rattachement.

Là où ça semble poser "problème", et c'est peut-être là l'origine du critère ajouté dans la validation, c'est que si une donnée n'a pas de géométrie géoréférencée, il n'est pas possible d'obtenir son état de validation par croisement spatiale. (l'absence de geom génère un point en coordonnées lat: 0, long: 0). Mais cette vérif n'aurait tout simplement pas à être réalisée si la donnée n'est pas géoréférencée.

Ce que je trouve dommage c'est que l'ajout du champ id_area_attachment n'ait finalement pas été exploité. Niveau performance il a un vrai intérêt (cf. #845 et #867 (comment)).
Qu'un géoréférencement d'une donnée de terrain saisie soit obligatoire j'en vois l'intérêt, mais concernant une donnée importée présente dans la synthèse c'est malheureusement loin d'être toujours possible et donc heureusement que la possibilité du rattachement spatial est là.

Je suis quand même curieux de savoir comment les utilisateurs de geonature gèrent le cas des vieilles données pouvant être localisées à la commune, au département ou sous tout autre zonage ? Et si c'est tout simplement la géométrie du zonage qui est stockée combien de données ça concerne et quelle part de MB ou de GB de stockage ça concerne ?

[camillemonchicourt]

Pour le fait d'exploiter un rattachement géographique pour ne pas dupliquer à plusieurs observations la géométrie de la commune à laquelle il se rattache, on est d'accord que ce serait utile et pertinent pour certains cas.
Mais il faut y travailler et ce n'est pas fait actuellement.

[pierre56]

Bonjour,

Je suis du même avis que @jbrieuclp, ce serait un chantier a faire et cohérent avec les pratiques.

---

Je n'ai encore quantifié le nombre de données ayant un id_area_attachement ainsi qu'une geom provenant de l_area.
Mais j'avais fonctionné comme cela lors de l'intégration des données serena non géoréférencée
donc volumétrie assez conséquence et implique que la synthese s'alourdisse beaucoup pour des polygones de commune
alors que tout vient de l_area a la base.

Pour l'intégration/export des données entre partenaires, on "hack" en mettant dans id_area_attachement de l'export l'area_code correspondant soit : le code maille, le code communes ou dep en fonction de la sensibilité.
Cela fonctionne aussi lorsque l'on a d'autres référentiels en commun (par ex, les sites chiro )
l'id de l_area est différent entre les bdd, mais tant que les codes sont communs et unique, ça marche bien.

---

En complément et fonctionnalité utile, ce serait intéressant pour Occtax.
Nous avons beaucoup de comptages qui se font plutôt sur un secteur qu'au point.
Par exemple, il y a des comptages qui se font depuis 30 ans sur les mm bassins et vasières et ce n'est pas nécessaire de pointer plus précisément.

Dans la "Liste de mes lieux", il faudrait :

• pouvoir sélectionner une liste parmi une liste de liste (site chiro, bassin/vasière, plage/secteur marin)
• Cette liste de liste proviendrait de l_area et afficherait les geom de la liste sélectionnée sur la carte
• En sélectionnant sur la carte un polygon, le relevé et l'obs serait rattaché automatiquement a l'objet et remplirait id_area_attachement dans la synthese. la saisie terrain serait sans doute plus rapide.

ça vaudrait sans doute un ticket dédié, si ça plait je le créerais mais c'était pour justifier/expliquer l'exploitation possible de id_area_attachement

---

Je serais curieux de voir les différences de perfs et de poids entre stockage et jointure chez moi🤔
@jbrieuclp tu utilises quoi comme outil pour analyser aussi finement ta BDD ?

bonne journée 😄

[jbrieuclp]

Je serais curieux de voir les différences de perfs et de poids entre stockage et jointure chez moi🤔
@jbrieuclp tu utilises quoi comme outil pour analyser aussi finement ta BDD ?

Les requêtes postgres :
https://www.postgresql.org/docs/13/functions-admin.html#FUNCTIONS-ADMIN-DBOBJECT
Tu pourras trouver plusieurs exemples d'usage sur l'internet.