Possibilité d’ajouter un niveau intermédiaire entre les sites et les visites «Transects »

Mounir-jelassi commented 3 years ago

Il s’agit d’un besoin spécifique pour le module de suivi du protocole POPReptile. On a besoin d’insérer un niveau « Transect » entre le site et la visite. En effet :

Ce niveau à une géométrie ligne (multipoints),
Pour chaque site on a plusieurs Transects
Pour chaque transect il y a plusieurs visites La solution nécessite d’avoir plus de flexibilité dans le générique

DonovanMaillard commented 3 years ago

Est-ce qu'en définissant 1site=1transect, et en utilisant les groupes de site, vous ne pouvez pas arriver au résultat attendu ? Les groupes de site sont déjà une notion en cours d'implémentation.

En soit, il "suffirait' d'avoir une notion de parenté entre les sites, comme on l'a avec les cadres d'acquisition, tel "site" est parent tous les autres.

Splendens commented 3 years ago

Dans le protocole POP Reptiles, on a une aire (groupe de site dans le générique) => qui contient des sites => qui eux mêmes contiennent des transects (multipoints matérialisant une ligne) => puis sur chaque transects il y a des visites/passages => et à chaque visite, au niveau des points ou des lignes entre 2 points, il y a ou non des observations.

J'imaginais aussi qu'on pourrait avoir un système des sites avec des hiérarchie. Ca éviterait de toucher à la BD pour ajouter des niveaux géographiques supplémentaires.

joelclems commented 3 years ago

Est ce que une visite sur un site reviens à faire tous les transect et à relever ce que l'on trouve sur les transect ? Est ce que les transect sont fixés par le protocole?

Si tel est le cas, on pourrait:

ajouter une table / un object transect pour stoquer les informations sur les transects:
- à quel site il est rattaché?
- sa geométrie
- ...

placer l'information sur les transect dans les observations


observation: {
id_transect
cd_nom,
informations spécifiques au module
}

Splendens commented 3 years ago

Les transects sont définis par les opérateurs de terrain. On peut ainsi avoir, dans une même aire étudiée, un site à un seul transect de 7 points (=points d'observations visuelles ou plaques abris), un autre site avec 12 transects de 4 et 5 points, etc.

Une visite/ passage se fait au niveau d'un transect, les observations devant être notées au niveau des plaques à reptiles ou des points d'observations et/ou de la ligne imaginaire se trouvant entre 2 points (lorsqu'on parcourt le transect).

Selon le protocole mis en place (POPR 1, POPR 2 ou POPR 3) les transects peuvent être amenés à bouger au sein d'un même site d'une année à l'autre. La notion de site est donc importante car il s'agit de l'unité d'échantillonnage au sein d'une aire d'étude.

Finalement, le plus simple serait de créer une table spécifique pour les transects si je comprends bien ? En plus, il n'y a pas que les protocoles POPReptiles qui utilisent des transects pour les suivis.

D'ailleurs, juste une idée qui me viens en écrivant : pour que le module monitoring puisse répondre de façon générique à tout types de suivis, ne faudrait-il pas aussi créer des objets "quadra" (je pense aux quadra phyto, ou aux transects + quadra combinés) ?

maximetoma commented 3 years ago

Pour vous rejoindre sur cette discussion, ne serait-il pas plus simple au final de pouvoir mettre une geom sur les tables t_observations et t_base_visits et de pouvoir configurer le type à l'instar des sites ?

Après pourquoi pas l'ajout de la table transect en plus au besoin

DonovanMaillard commented 3 years ago

A la lecture de tout ça, je pars un peu loin, mais on pourrait imaginer à termes :

De ne pas définir en dur le nombre de niveaux (actuellement site + visite + observation) d'un sous-module
Ca pourrait se définir dynamiquement dans la conf du module, comme aujourd'hui avec l'arborescence qui détaille le lien entre les objets.
Puis définir, du coup, dans cette arborescence, chaque json à aller charger et son "niveau"
Coté base, ça ferait à peu près tout dans une même table : un id_module, un "niveau" qui indique le formulaire en question, un "id_objet' (nos actuels id_site, id_visite etc), un id_object_sup ou une table de correspondance pour dire à quoi c'est rattaché au dessus, un geom s'il existe, et que du json derrière
Pour les géom, un widget comme un autre, présent ou non dans la conf du formulaire, qui affiche ou non une carte en interface...

Ca ouvrirait la porte à tous les cas de figure, avec X formulaires imbriqués les uns sous les autres, avec ou sans geom à chaque niveau, avec toutes les infos nécessaires dans un json. Et des vues bien sympa à mettre en place pour alimenter les exports et la synthèse

Je sais pas s'il faut intégrer spécifiquement des transects, des quadrats etc, en réalité des méthodes comme celes là il en existe un paquet...

camillemonchicourt commented 3 years ago

Hum il faut vérifier si on n'est pas en train de demander à un module générique de répondre à tous les cas spécifiques ? Ce n'est pas le but de ce module.

On a déjà ajouté un niveau supplémentaire qui n'était pas identifié dans les besoins initiaux : les groupes de sites. Ils servent justement à pouvoir avoir des points de passage (sites) sur un transect (groupe de sites).

Si il faut encore ajouter un niveau mais qu'il est utilisé que dans certains cas, alors on sort trop des limites de la généricité et simplicité du module selon moi. Et cela va devenir complexe à gérer, maintenir, tester. Et pour quel usage et utilisation ? Comment gérer tous les niveaux, les interfaces, les exports etc...

Si il y a tous ces besoins spécifiques en dehors du cadre initial alors je pense qu'il vaut mieux faire un module dédié.

Splendens commented 3 years ago

Pour moi, un module générique doit pouvoir présenter pleins de paramétrages possibles à partir d'un même socle, afin de répondre au plus grand nombre de cas. Ici ce serait un module de suivi de base, pouvant être décliné en de multiples protocoles différents, et pas seulement un site (lieu)-> des visites (dates)-> des observations (taxons). Là on n'est pas dans un cas de module générique et déclinable, mais juste d'un module très simple adapté à des "protocoles" tout aussi simples (qui ressemblent beaucoup ici à des données opportunistes sur un même site).

Sinon, de façon un peu caricaturale, on pourrait utiliser occtax pour ce genre de suivi : je garde ma géométrie, que je réutilise dès que je refais un relevé sur la zone (c'est une façon détournée de faire un suivi de site).

S'il y a tous ces besoins spécifiques en dehors du cadre initial alors je pense qu'il vaut mieux faire un module dédié.

Ou alors il faut redéfinir le besoin initial ? Si le besoin est de pouvoir avoir un module de suivi pour les suivis de sites, et bien ces suivis ont souvent des protocoles complexes, à plusieurs niveaux :

une aire d'étude : la zone étudiée dans laquelle on va échantillonner (une forêt, une bande littorale, etc. Bien que la nécessité d'une géométrie à ce niveau soit discutable dans certains cas)

regroupant

des sites : des zones d'échantillonnages de l'aire suivi (une zone à parcourir, un transect, quadrats, point de tamisage, point d'écoute, etc.)

regroupant parfois

des sous-unités géographiques (transects, quadrats, point de tamisage, point d'écoute, etc.)

regroupant parfois

des sous-unités géographiques (transects, quadrats, point de tamisage, point d'écoute, etc.)
peut-être qu'il y a d'autres types de découpages ?

dans lesquelles

on fait des visites / passages à certains moments de l'année, et lors desquels on fait (ou non) des observations.

On peut alors conceptualiser les différents types de suivis de sites de façon générique, en imaginant les sites comme des entités géographiques avec une notion de hiérarchie.

Si on se dit que dès qu'il y a un transect ou un quadrat, on doit développer un module à part, alors on va pouvoir développer un module PopReptiles, un module PopAmphibiens, un module suivi des tulipes sylvestre, un module suivi des prairies à fritillaires, un module de suivi des grèves de Loire, un module de suivi des arthropodes du littoral, etc.

Alors que la spécificité se trouve dans les détails : quels groupes taxonomiques je suis (flore ? reptiles ? tulipes ?...), des infos nécessaires aux protocoles (données de météo ? granulométrie ? etc.)

Est-ce qu'un seul module générique et paramétrable est moins délicat à gérer et maintenir que X modules spécifiques ?

camillemonchicourt commented 3 years ago

C'est idéal d'avoir un module générique qui gère le plus de cas spécifiques possibles. Mais il faut aussi voir jusqu'où on va et jusqu'où on peut aller en terme de maintenance dans le temps.

joelclems commented 3 years ago

Je verrai bien

rajouter une table pour les éléments de precision géographique.

ces éléments peuvent être des pièges, des placettes, des quadra, des points libres mais aussi des géométries libres, des transects, etc...

ils sont rattachés à un site ( 1 site - [0,n] précisions géographiques ), besoin de réuitlisation
ils permettent d'enrichir une observation en tant que précision géographique ( 1 observation - [0,n] précision géographique)

plusieurs possibilités donc:

si la relation precision-géographique d'une observation contient:

rien du tout: c'est une observation sans précision géographique
un seul élément: l'observation à eu lieu sur cet élément (ou pas très loin à voir comment le quantifier)
plusieurs éléments: l'observation à eu lieu sur un tracé qui est défini par ces éléments (transect) (ou pas très loin à voir comment le quantifier)

En précision : un transect peut être ici défini ici par

plusieurs éléments de précision géographiques : c'est par exemple le trajet (plus ou moins direct) entre deux placettes
un element de géomtrie multiligne d'un seul morceau

A voir comment faire en frontend pour rendre cela joli et pratique à tous les niveaux

pour recontextualiser dans ce cadre:

groupe de sites : groupement à l'échelle d'une commune
site : là où l'on se rend pour faire des observations
visite : quel site, qui , quand, dans quel contexte (jdd, météo, etc...)
observation: quoi, autres(?? denomenbrement ? besoins de sous-object ??)
précision géographiques: vient se placer entre les sites (utile pour la réutilisation) et les observations

reste à trouver un nom parce que précision géographiques c'est un peu long

Adrien-Pajot commented 2 years ago

Cette notion de site/sous-site est en effet très intéressante dans de nombreux protocoles où l'aire d'étude est une première donnée, aire dans laquelle de nombreux points/lignes/polygones sont monitorés dans le temps. Un protocole s'axant sur plusieurs aires.

Dans le cas des TAAF sur lequel nous travaillons, des protocoles comme le suivi des nids de pétrels (ou de n'importe quelle autre espèce d'oiseaux de là-bas) sont définis selon plusieurs sites d'études au sein desquels chaque nid est monitoré dans le temps. Si besoin je peux faire un schéma.

A réfléchir dans le cadre de #117 ?

camillemonchicourt commented 2 years ago

On a déjà la possibilité d'avoir une aire (groupe de sites) regroupant plusieurs sites.

Adrien-Pajot commented 2 years ago

Et la possibilité d'avoir plusieurs aires dans un protocole ?

joelclems commented 2 years ago

oui la hierachie des objets peut être al suivante:

- module (ou protocole)
  - groupes de sites  (ou aire)
    -  sites
      - visites
        - observations

cela se passe dans les fichiers config.json

par exemple

https://github.com/PnX-SI/gn_module_monitoring/blob/787b7c6d8ad8629299ed766f345f5518b4c955ea/config/monitoring/generic/config.json#L2-L10

https://github.com/PnX-SI/gn_module_monitoring/blob/787b7c6d8ad8629299ed766f345f5518b4c955ea/contrib/POPAmphibien/config.json#L2-L12

PnX-SI / gn_module_monitoring

Possibilité d’ajouter un niveau intermédiaire entre les sites et les visites «Transects » #63