Observations sur 3 niveaux: Zones, individus et observations

[xdidx]

Bonjour,
Toujours au sein de la prestation pour CREA Mont-Blanc, j'aimerais développer un système d'observations sur 3 niveaux:

1. Les zones d'observations qui ont une position et un rayon (fixe au départ, de 500m)
   

2. Les individus liés à une zone d'observation et chacun associé à une espèce
   

3. Les observations liées à un individu (Chaque observation est associée à une étape d'un stade phénologique. L'image ci-dessous affiche par exemple les différentes étapes du stade de floraison)
   

J'aimerais votre avis sur plusieurs aspects:

• La possibilité d'utilisation de tables déjà existantes en base: La table des sites peut-être utilisée pour les zones d'observations ou les individus ou vaut-il mieux créer des tables séparées? Pareil pour les observations ?
• L'altitude de la zone d'observation pourrait-elle être un champ en base de donnée ou nécessite-t-elle un champ dans une colonne JSON schéma ?

N'hésitez pas si vous avez d'autres remarques sur cette fonctionnalités,
Merci d'avance !

Edit 2022: cf PR #337

[camillemonchicourt]

De ce que je comprends, ça serait entre la logique de site et d'occurrence de taxons.
Mais ni vraiment l'un ni l'autre ?

Est-ce qu'on revient à différente date sur une zone ? Ou elle est uniquement liée à une observation une fois ?

Est-ce qu'on localise chaque observation en plus de la zone, ou alors on localise uniquement la zone ?

[xdidx]

Merci pour cette réponse rapide !

Effectivement, je vois ça aussi comme un mélange des deux, mais plus "complet" car avec un niveau supplémentaire (si on considère que les observations simples sont à 1 niveau, et que les sites/visites sont sur 2 niveaux)

Une zone peut être utilisée plusieurs fois, avec un nombre d'individus et d'observations potentiellement infini.

Une observation est bien localisée (au sein de la zone) en plus de la localisation de la zone elle même.

[camillemonchicourt]

Si on peut revenir sur une zone, alors il me semble que c'est un site, dans une logique de suivi, que l'on peut donc y faire des visites dans lesquelles on peut faire des observations.

Mais cela pose en effet pas mal d'autres questions.

[xdidx]

Bonjour,
Suite à nos discussions, j'aimerais qu'on voit ensemble pour créer une structure de données adéquate et modulable à Géonature Citizen.

Voici à quoi j'ai pensé:

• Ajout d'une table t_sites_groups (id_group, id_program, name, geom, timestamp_create, timestamp_update, id_role, obs_txt, json_data)
• Ajout de la colonne id_group dans t_sites
• Ajout de la colonne id_sites_group_form dans t_programs (afin d'avoir les colonnes spécifiques au programme dans le formulaire d'un groupe de site)

Voici un MCD complété à partir de ces idées:

Bonne soirée !

[camillemonchicourt]

Oui si la notion de groupes de sites colle bien, alors cela me semble une bonne solution, plus générique.

[xdidx]

Je viens de penser à un élément oublié: l'id de l'espèce lié à l'individu (lié au site si on se base sur la base de données).
Est ce que ça vaut le coup d'associer le site à une espèce si il y a un groupage des sites? Aurais-tu une meilleure idée ? Ou vaut-il mieux utiliser d'autres tables?

J'ai une autre question qui n'a pas directement à voir: Est ce que c'est possible de traduire les noms des champs d'un formulaire créé à partir d'un JSON schema?

[camillemonchicourt]

A voir comme cela peut être géré, car généralement pour les suivis l'espèce est au niveau de l'observation, elle-même associée à une visite, elle-même liée à un site.
Dans le cas différent (et plus particulier) où l'espèce est au niveau du site, je ne sais pas trop comment gérer ça de manière cohérente et générique.

Oui pour les traductions, j'imagine que OUI, mais je ne sais pas comment.

[xdidx]

J'ai décidé de partir sur une autre base, avec un schema gnc_areas, des tables t_areas, t_individual et un champ id_individual sur la table t_obstax.
J'ai hésité à créer une table d'observations spécifique aux individus, pour éviter de dupliquer les champs cd_nom, id_program et geom mais je pense (sans grande conviction) que c'est préférable d'utiliser la même table pour réutiliser facilement tout ce qui est basé sur les observations "basiques".

Dans ce schéma, on ne voit pas les deux champs qui contiennent les schémas JSON pour les zones et les individus dans la table t_programs

Qu'en penses-tu ? :)

[camillemonchicourt]

Du coup tu créerais un autre truc à part, avec un troisième type de programme ?
Pourquoi pas, même si je m'interroge sur le fait que les zones ne sont pas vraiment différentes des sites ?

[xdidx]

Effectivement, une zone est assez similaire à un site, comme un individu est similaire à un site, juste avec l'association à une espèce en plus.

Je pense bien faire un troisième type de programme spécifique pour faciliter un peu le tout:

• Dans la base de donnée, les tables et données seront bien différenciées et non mélangées, pas de champ vide ou dupliqué en fonction du module.
• Dans la création du programme, on aura le choix entre observations, sites ou zones individus, plutôt que d'avoir une option de groupage si on sélectionne le module site.
• Moins de problématiques de généricité et donc facilitation de la validation du schéma

Dans ce sens, je pense finalement faire une nouvelle table d'observations associée aux individus afin de ne pas dupliquer l'espèce, la localisation et le programme, et aussi pouvoir y associer des stades phénologiques sans modifier la table des observations "simples".

Edit:
Voici un schéma complet mis à jour:

On a donc comme fonctionnalités principales:

• Des zones de suivi (t_areas)
• Avec des sites liés à une espèce (t_species_sites)
• Sur lequel on fait des observations (t_species_sites_observations)
• En y associant l'étape d'un stade (t_stages_steps)
  Cette étape (t_stages_steps) est par exemple: "Plus de 50%" sur le stade de "Floraison" (t_species_stages)

Autres infos:

• Chaque zone de suivi peut être utilisée par plusieurs personnes en fonction des droits déterminés (t_areas_access)
• Chaque site, observation et stade pourra avoir des photos associées
• Les photos associées à un stade auront un type. En effet, chaque stade aura 3 photos de démonstration, une pour la période avant ce stade, une pendant celui ci et une après. Ça permettra de mieux faire comprendre aux utilisateurs à quoi correspond réellement le stade sélectionné.