Module CMR - Définition du projet

[camillemonchicourt]

Mise en place d’un module de gestion des données issues des protocoles de type CMR - Capture Marquage Recapture

Premier jet par @DonovanMaillard

La CMR est une méthode d’étude des populations végétales et animales reposant sur la Capture, le Marquage d’individus, et leur Recapture (ou non) à Posteriori.

Par des méthodes statistiques simples, il est possible ainsi d’estimer la taille de populations données.

Une autre utilisation de la CMR est l’étude du déplacement d’individus depuis un site (site réservoir), ou les échanges entre deux sites (flux de gènes entre 2 mares par exemple).

Dans tous les cas, l’entrée principale est l’individu marqué, auquel sont associées différentes informations, notamment les lieux et dates de marquage, de recapture etc. Une autre entrée importante est le "site", s’agissant de suivis.

Coté base de données

3 tables clé semblent essentielles.

Une première définit le ou les sites d’études (notamment de marquage). Attention, ils ne sont pas "exclusifs" dans le protocole (un individu qui se déplace peut être capturé hors du site où il a été marqué).

Table 1 : t_site

La seconde table répertorie les individus de la, ou des espèces suivies, avec leur marquage. N° de bague, n° écrit sur l’aile, code couleur, reconnaissance du masque facial, motif sous le ventre des sonneurs etc

Table 2 : t_individus

La dernière table répertorie les actions de Marquage, de Recpature, et d’éventuelles prises d’informations sur les individus (sexage, biométrie etc).

Table 3 : t_operation

Coté utilisateur / Interface

L’utilisateur doit pouvoir, au choix, travailler à l’échelle du site (id_site renseigné, the_geom_action NULL), ou au point GPS pour davantage de précision (le point peut alors se retrouver dans un site, ou en dehors pour une recapture qui se ferait hors d’un site suivi).

Par défaut, date max = date min et haure max = heure min, mais peut être changé par l’observateur avec un petit "+" comme fait sur occtax.

Niveau interface, l’opération Capture/Marquage impliqué l’écriture d’une nouvelle ligne dans la table individus, et donc de renseigner les champs qui correspondent.

Un certain nombre de champs, dans la plupart des cas, peuvent ne pas être renseignés à chaque recapture (par exemple la biométrie peut ne pas être faite à chaque fois). D’autres peuvent ne pas évoluer le plus souvent (le sexe, qui n’évolue que dans de rare cas au cours de la vie d’un individus, ou qui peut n’être déterminable qu’à partir d’un certain stade).

Pour l’utilisateur :

Les sites :

Le module permet d’identifier un ou certains sites de suivis, comportant les informations suivantes :

• un identifiant,
• un nom,
• une description du site,
• et sa forme géométrique (on stocke son polygone au format carto).

Ces sites sont informatifs et regrouperont en principe la majorité des données. Cependant on peut sortir de ces sites (recapture d’un animal marqué, hors de son site), ou alors on peut être plus précis (sur mon site de 1800m2, tel individu a été marqué à ce point gps précis). Ça peut par exemple permettre de redéfinir les sites d’étude.

Les actions :

On peut, dans le cadre de ce suivi, effectuer 2 opérations :

1. Une capture avec Marquage :

Dans ce cas, on va renseigner des informations concernant l’action, et l’individu marqué :

• Qui est l’opérateur (observateur et marqueur) • Méthode de détermination / de capture • Date et heure de la capture/marquage • Qui est le déterminateur (la détermination n’a lieu qu’à la capture, pas aux recaptures) • Méthode de détermination • Espèce • Quel marquage (numéro, couleur, photo? ) • Précision sur le marquage (organe marqué par exemple) • Site de capture • Eventuellement, pointage de la capture (sinon, rattachement au site) • Sexe de l’individu • Stade • Etat (mort/vivant) • Eventuellement, certains éléments de biométrie • Eventuellement, photo ?

2. Une recapture :

• Opérateur • Date et heure de recapture • Eventuellement, Site de recapture • ou Eventuellement, pointage de la capture (sinon, rattachement au site) • Individu recapturé • Sexe de l’individu • Stade • Etat (mort/vivant) • Eventuellement, certains éléments de biométrie • Eventuellement, photo ?

A l’arrivée :

• On peut facilement identifier tous les individus d’un site
• On peut facilement identifier tous les sites visités par un individu
• On peut facilement connaitre les liens et les échanges d’individus entre les sites
• On peut facilement suivre l’historique d’un individu (évolution de la biométrie, évolution des déplacements, du nombre de recaptures, lieu de capture, date de marquage et de recapture etc)
• On peut facilement utiliser ces données pour les statistiques d’estimation des populations (on a le nombre d’individus total, le nombre recapturés à chaque visite).
• Ces données sont compatibles avec l’occurrence de taxon pour être renvoyées vers la synthèse.

[TheoLechemia]

Premier jet du MCD, avec intégration des pseudos champs pour les programmes CMR plus complexes:

[gildeluermoz]

Théo. Joli coup ! QQ remarques :

• Y'a pas un soucis au niveau de ta cor_program_attribut. Ta cor_program_attribut correspond (si tu enlèves le id_program) à une bib_attributs. Et ta cor_program_attribut viendra entre les deux.
• Cette bib_attributs pourrait d'ailleurs être générique à gn_monitoring (voir à gn_commons) et servir pour définir des attributs que tu peux utiliser de manière ultra générique dans des formulaires avec un composant (comme pour nomenclature). On peut mettre dans cette bib_attributs un id_type_nommenclature, comme ça si tu as un nouvel attribut, tu définis une nouvelle nomenclature et hop son contenu monte tout seul dans le formulaire ....
• Dans pr_cmr, bib_attribut servira aussi pour cor_operation_attribut *t_operations
  • devrait être une fille de gn_monitoring.t_base_visites qui comporte le lien vers le site, le digitiser et datemin max
  • faut-il un nouveau geom pour l'opération dans un site qui a déjà un geom ?
  • la notion de déterminateur est-elle vraiment utile ? En cmr, les opérateurs doivent savoir ce qu'ils observent. Non ?
  • pour le standard sinp, un unique_id_sinp_grp serait utile (voir la nomenclature des types de regroupements)
  • le sexe ne doit pas changer pour un individu d'une opération à l'autre. Ca irait plutôt dans t_individuals. Non ?
  • Est-ce qu'il n'y a pas des champs de t_operations qui irait en attribut pour être dans cor_operation_attribut. En tout cas tout ceux qui ne seraient pas obligatoires pour tous les programmes (bio_condition, life_stage, determination_method, autre ?). Ça serait plus souple.
• Rename cor_site_protocol --> cor_site_program
• t_individuals :
  • ton individus n'appartient pas à un site (id_site_tag + la patte vers t_base_sites)? Tu le rattaches à un site via l'opération durant laquelle il est vu. Non ? D'ailleurs tu as un id_site dans t_operations. Il te manque donc une patte de t_operations vers t_base_sites ou t_programs.
  • Il y a un truc à éclaircir sur le positionnement dans le ou les sites des individus, des opérations et des programmes. Y'a qq chose qui m'échappe. Pour moi le id_site va dans t_operations. c'est ça qui est factuel. Tu visite un site à un instant T, pour un programme P et tu vois ce que tu vois (le ou les individus I)
• Grosse lacune il me semble : on ne peut pas rattacher les individus à un programme. Donc quand tu veux, en interface lister les individus pour un programme CMR des sonneurs à ventre jaune par exemple, à part filtrer sur le taxon, tu pourrais faire remonter des chamois dans ta liste venant de t_individuals. Et même si tu filtres sur les taxons, le suivi des sonneurs du champsaur proposera tous ceux d'Embrun... J'ajouterais une cor_individual_program et je supprimerais la patte entre t_base_sites et t_individuals

[TheoLechemia]

Y'a pas un soucis au niveau de ta cor_program_attribut. Ta cor_program_attribut correspond (si tu enlèves le id_program) à une bib_attributs. Et ta cor_program_attribut viendra entre les deux.

En gros c'est une bib_attribut par programme. Chaque programme a sa liste d'attributs complémentaires. D'ou le id_program

On peut mettre dans cette bib_attributs un id_type_nommenclature

Complement d'accord. C'est un oubli

ton individus n'appartient pas à un site (id_site_tag + la patte vers t_base_sites)? Tu le rattaches à un site via l'opération durant laquelle il est vu. Non ?

C'est le site initial de capture de l'individu (utile pour remonter tous les indivus d'un site) Il peut ensuite être vu sur un autre site, ou meme hors site (d'ou la geom dans t_opérations).

Grosse lacune il me semble : on ne peut pas rattacher les individus à un programme.

Bien vu

[TheoLechemia]

MAJ

[laurentbarthe]

Bonjour à tous, Des structures ont avancée sur un module CMR ? La Société Herpétologique de France souhaite développer un module pour les CMR cistude et proposer ensuite cet outil dans le cadre du PNA. Nous aimerions profiter de cette occasion pour relancer la démarche module CMR en créant peut être un petit groupe de travail de structures intéressées ?

[DonovanMaillard]

Perso je repartirais sur #3 , l'arrivée du module de suivi a largement élagué le sujet et nous permet des choses plus simples et plus efficaces que ce qui avait été imaginé à la base.

[camillemonchicourt]

Il a été retenu d'intégrer le concept d'individus dans le module Monitoring plutôt que de le dupliquer en grande partie dans un module spécifique CMR : https://github.com/PnX-SI/gn_module_monitoring/issues/213