Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
jbrieuclp opened this issue Jan 10, 2024 · 6 comments
Open

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

jbrieuclp opened this issue Jan 10, 2024 · 6 comments

Comments

@jbrieuclp
Copy link
Contributor

Salut,
Depuis déjà plusieurs versions il est possible de renseigner une localisation via un ID de la table ref_geo.l_areas. De notre côté je l'utilise pour stocker des données communales, départementales et régionales qui ont été importées sans exploser la base avec le stockage des géométries pour chaque occurrence. Je renseigne donc le champ id_area_attachment et laisse vide les champs geo (the_geom_4326, the_geom_local, et les centroïdes).
Concernant la visu sur la synthèse ou l'export, j'ai modifier les vues pour recupérer la geométrie. Ca fait longtemps que je fonctionne comme ça et ca fonctionne très bien.

Maintenant dans la validation il y a la ligne suivante qui ajoute le critère the_geom_4326 IS NOT NULL et qui exclue une partie des données du module validation.

query = query.filter(Synthese.the_geom_4326.isnot(None)).order_by(Synthese.date_min.desc())

Maintenant pourquoi ce critère avait été historiquement ajouté ? A t-il toujours sa raison d'être ou peut-il maintenant être supprimé ?

@camillemonchicourt
Copy link
Member

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
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Contributor

pierre56 commented Jan 18, 2024

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
Copy link
Contributor Author

jbrieuclp commented Jan 18, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants