search

PnX-SI / gn_module_monitoring

Module GeoNature de suivi générique pour protocoles de suivi simples
GNU Affero General Public License v3.0
6 stars 24 forks source link

Attribuer des géométries aux visites/observations #37

Open maximetoma opened 4 years ago

maximetoma commented 4 years ago

Bonjour, nous avons commencé à tester le module monitoring avec Frédéric ROBIN de la LPO et nous arions une question concernant la mise en place d'une géométrie sur les niveaux "Visites" et "Observations".

Nous aurions un exemple d'utilisation qui est le "distance sampling" (évaluer une population autour d'un transect par exemple) où l'on définirai un site avec une geom polygonale et des visites (et/ou observations) ayant une geom également mais ponctuelle par exemple.

A vous lire, Maxime

camillemonchicourt commented 4 years ago

Ce n'est pas planifié actuellement mais c'est pas la première fois que cela est évoqué.

Adrien-Pajot commented 3 years ago

En lien avec #117 ?

camillemonchicourt commented 3 years ago

Je ne vois pas de lien avec le fait de pouvoir entrer par site

Adrien-Pajot commented 3 years ago

Je me disais site/sous-site/groupes de sites et tous les sujets traités autour de ces lieux dont j'essaie de creuser les tickets

camillemonchicourt commented 3 years ago

Oui actuellement on a des groupes de sites et des sites. On a discuté plusieurs fois d'ajouter des sous-sites. Donc ça donnerait plutôt : Groupes de sites / Sites / Sous-sites Voire Groupes de sites / Sites / Sous-sites / Sous-sous-sites ... si on utilise de la récursivité

ClaireLagaye commented 11 months ago

Bonjour,

Je vois que cela a déjà été évoqué mais je ne vois pas où ça en est et je me permets de relancer. Nous souhaiterions migrer nos protocoles IPS/IPA (actuellement sous geomatika) sur le module monitoring et le problème est qu'il faut localiser sur la carte chaque observation pour calculer ensuite la distance entre le point d'observation et le groupe d'animaux. Je n'ai pas trouvé de widget de type geometry, est-ce prévu ?

Notre protocole est le suivant Sites - une 20aine de polygones (Quartiers de comptage) associés à des points ou des lignes (point ou trajet d'observation) Visites - 3 par an, on y enregistre observateurs, date, météo, etc Observations - 1 point par groupe d'animaux, on y enregistre les heures et nombre d'animaux par sexe/classe d'âge

Merci !

camillemonchicourt commented 11 months ago

Ça serait intéressant et utile dans certains cas, mais pas de développement prévu ni financé sur le sujet actuellement à ma connaissance. Possible de contribuer sur le sujet si vous voulez.

CynthiaBorotPNV commented 2 months ago

Bonjour,

Je vois que cela a déjà été évoqué mais je ne vois pas où ça en est et je me permets de relancer. Nous souhaiterions migrer nos protocoles IPS/IPA (actuellement sous geomatika) sur le module monitoring et le problème est qu'il faut localiser sur la carte chaque observation pour calculer ensuite la distance entre le point d'observation et le groupe d'animaux. Je n'ai pas trouvé de widget de type geometry, est-ce prévu ?

Notre protocole est le suivant Sites - une 20aine de polygones (Quartiers de comptage) associés à des points ou des lignes (point ou trajet d'observation) Visites - 3 par an, on y enregistre observateurs, date, météo, etc Observations - 1 point par groupe d'animaux, on y enregistre les heures et nombre d'animaux par sexe/classe d'âge

Merci !

Bonjour,

Pour remettre ce sujet à l'ordre du jour, nous avons effectivement besoin au PNV dans le cadre des protocoles IPS/IPA chamois et bouquetins de créer 1) des sites avec une emprise sous forme de POLYGON mais aussi de géolocaliser soit la trace du parcours LINE réalisé par l'observateur soit le point fixe POINT qui restent identiques dans le temps, donc l'ajout d'une seconde géométrie. 2) pour les visites les besoins sont standards, 3 à 4 visites par site 3 ) pour les observations, nous avons besoin de géolocaliser les groupes d'animaux observés depuis le point ou la trace.

Je suis en mesure de réaliser une partie du développement de ces 2 fonctionnalités et donc, je souhaitais avoir votre avis sur la modification ou non du modèle de données. Si je comprends bien : Cas 1) les géométries sont stockés dans un champ de type GEOMETRY Cas 2) Les géométries sont stockés dans les champs optionnels en JSON

camillemonchicourt commented 2 months ago

OK, merci pour ces éléments.

La structure de données de Monitoring (gn_monitoring) s'appuie sur une géométrie qui est celle du site. Dans les concepts, on a un site qui est l'élément de base géolocalisé. Et ensuite on associe des visites et des observations sur celui-ci.

Donc selon moi, c'est problématique de complexifier et apporter de la confusion en ajoutant d'autres champs de géométrie dans la BDD, car ils seraient potentiellement redondants et on ne comprendrait plus le modèle et la structure des données. D'autant plus si c'est vraiment dans des cas très particuliers et isolés qu'on a besoin de géométries secondaires ou complémentaires. Donc je privilégierai plutôt de les gérer comme des champs additionnels comme les autres champs spécifiques à certains protocoles. Mais c'est peut-être trop complexe et pas assez solide de les stocker comme les autres champs additionnels.

Sinon, si c'est un besoin fréquent et qu'il doit être plus solide et structuré dans la BDD, ajouter des vrais champs de type GEOMETRY mais en les nommant clairement pour qu'on comprenne qu'ils sont secondaires et optionnels ? 🤔

DonovanMaillard commented 2 months ago

Sans savoir si c'est une bonne ou une mauvaise idée,il y a une 3eme solution technique possible,c'est de fonctionner comme les medias ou autre. Avoir une table tranversale avec un identifiant, le type d'objet (groupe de sites, site, visite, observation), et un vrai champ géometry.

C'est ensuite dans la conf du module qu'on indique à quels niveaux on doit faire appel à une geom ou non : par défaut site et groupe de site uniquement.

camillemonchicourt commented 2 months ago

OK OK, c'est une piste intéressante.

Ça me pose soucis pour la cohérence, la lisibilité et la compréhension que de rajouter des champs de géométrie un peu partout et à tous les niveaux. Mais ce n'est pas non plus très rassurant et solide que des gérer des champs de géométrie dans le champs JSON de données additionnelles.

Par contre si tu imagines que toutes les géométries de Monitoring seraient gérer comme ça dans un table transversale de géométrie, je pense que c'est trop, complexe et peu structuré.

Donc je garderai clairement le champs principal et essentiel de géométrie dans la table des sites, et continuer à structurer les monitoring autour de champs et du principe que la géométrie de base est celle du site.

Mais en donnant la possibilité d'avoir une géométrie secondaire au niveau du site, de la visite ou des observations dans cette table de stockage des géométries secondaires, avec un moyen de le configurer dans la config des sous-modules.

Ça me semble une bonne solution comme ça.

CynthiaBorotPNV commented 2 months ago

Est ce que, à l'image des tables t_*_complements, ne pourraient-on pas créer les tables :

maximetoma commented 2 months ago

Nous avons aussi une problématique similaire où nous disposons de doubles géométries pour certains de nos suivis (typiquement nous relevons des X/Y sur des individus rattachés à un site ou un transect par exemple)

La troisième solution évoquée par @DonovanMaillard semble intéressante, on peut également ajouter plus facilement un index spatial sur un champ geom en dur.

Concernant ta proposition @CynthiaBorotPNV, je la trouve cohérente vis-à-vis du schéma mais je trouve qu'on va rajouter une complexité supplémentaire sur le schéma gn_monitoring qui présente déjà beaucoup de tables.... Je propose plus de la mettre sous une forme de table de corrélation du type cor_geom_module avec un champ geom, un champ id_module, un champ id_objet (sites, visit, observation...), et un champ id_source ? Ou alors, carrément rajouter la colonne geom dans les tables _complements existantes ?

camillemonchicourt commented 2 months ago

Est ce que, à l'image des tables t_*_complements, ne pourraient-on pas créer les tables :

  • t_sec_geom_site
  • t_sec_geom_visit
  • t_sec_geom_obs

Les tables t_*_complements sont historiques mais ces tables avec des relations 1-1 ne sont pas idéales et voués à disparaître pour fusionner avec les tables qu'elles étendent. Donc pour des géométries secondaires pour moi ça reviendrait au même que d'ajouter un champs geom_secondaire dans les tables principales des sites, visites et observations. Donc je privilégierai plutôt de faire directement cela, ou d'avoir une table centrale et transversale avec les géométries secondaires (ma piste préférée).

Pour moi cette table n'aurait pas besoin d'id_module. Un champs "geom" et un champs "id_object" (voire même "uuid_object" ?).

CynthiaBorotPNV commented 2 months ago

Les tables t_*_complements sont historiques mais ces tables avec des relations 1-1 ne sont pas idéales et voués à disparaître pour fusionner avec les tables qu'elles étendent. Donc pour des géométries secondaires pour moi ça reviendrait au même que d'ajouter un champs geom_secondaire dans les tables principales des sites, visites et observations. Donc je privilégierai plutôt de faire directement cela, ou d'avoir une table centrale et transversale avec les géométries secondaires (ma piste préférée).

Dans mon idées ces tables pourraient être des table 1-n, donc avec la souplesse de pouvoir associer 1 à n géométries secondaires à l'objet, faisable aussi avec la proposition de @DonovanMaillard

maximetoma commented 2 months ago

Si je résume l'idée, on pourrait avoir une table 1-n nommée t_additional_geoms avec :

CynthiaBorotPNV commented 2 months ago

On peut peut-être se passer d'un id supplémentaire et supprimer id_add_geom.

Par contre le fait d'avoir un champ du type uuid pointant sur différentes tables oblige à mettre en place des check pour compenser la vérification naturelle de l'intégrité référentielle par FK.

Exemple dans mon module 'Suivi Geek' mes sites sont constitués ainsi :

Au delà du type, il faudrait pouvoir caractériser ces géométries avec un champ supplémentaire afin de pouvoir les classer entre elles sur l'ensemble du module. Exemple de table :

t_module_type_geom :

... mais ça complexifie bien les choses

DonovanMaillard commented 2 months ago

L'idée peut être aussi de ne pas parler de géom additionnelle, mais simplement de geom. Et du coup, de ne plus avoir de geom sur la t_base_sites, puisqu'on stocke les geom sur une table transversale.

Si on adopte cette logique que chaque objet peut avoir une géométrie, il n'y a pas besoin de conserver un fonctionnement différent pour les sites. Du coup ca ferait plutôt une cor_object_geom ou une t_geoms

camillemonchicourt commented 2 months ago

Ça je suis carrément moins chaud de pas garder une structure fixe et solide avec le concept central que la géométrie de référence et de base se trouve au niveau du site.