Projet (peut-être) de développement d'un module Chronoventaire

[DonovanMaillard]

Le protocole

Le principe de base du protocole chronoventaire est de faire se succéder des "mini inventaires" de quelques minutes sur un site, et de recenser pour chaque session les espèces rencontrées. Ce découpage permet de regarder, toutes les x minutes, si de nouvelles espèces ont été observées ou non. Si aucune nouvelle espèce n'a été recensée après 3 sessions, on considère qu'on a atteint un plateau, et que l'échantillonnage est optimisé.

Cette courbe cumulée croissante représente donc le nombre cumulé d'espèces (en Y) en fonction du rang de la session (en X). Si un inventaire n'est pas terminé, la courbe n'atteint pas de plateau. Si un élément (pluie ou autre) vient perturber le relevé, une cassure s'observe et le plateau s'atteint brutalement, par manque d'observations. Si l'échantillonnage est de "bonne qualité", la courbe atteint progressivement un plateau, atteignant le nombre d'espèce attendu pour le site échantillonné.

SAISIE

Modifications à apporter à occtax pour que le module soit adapté à la saisie des données chronoventaire :

Relevé :

• Ajouter le calcul ou la définition (comme pour les altitudes) de la surface échantillonnée, dans la BDD et dans le front
• Ajouter un champs pour le milieu : champs texte ou nomenclature à choisir ?

Session :

• Entre le relevé et l'occurrence, ajouter la notion de session. Chaque session contient une ou des occurrences (ou pas d'occurrence!), contenant un ou des dénombrements
• La session doit comporter un numéro (défini d'office) qui n'alimente pas la synthèse, et un commentaire de session (soit n'alimente pas la synthèse, soit se concatène avec le commentaire d'occurrence ?)
• Éventuellement prévoir un champs pour la durée de session, avec une valeur par défaut (5mn selon le protocole)
• Le nombre de session n'est pas limité

Occurrence :

• Pas de modification identifiée

Dénombrement :

• Pas de modification identifiée

CONSULTATION SUR L'ACCUEIL DU MODULE

Il serait intéressant d'avoir un graph de richesse cumulée, session par session au sein d'un relevé, qui se calcule au fil de la saisie. Nombre d'espèce cumulée en Y, numéro de session en X. Ce graph pourrait se retrouver sur l'accueil du module et apparaitre lorsqu'on clique sur un relevé. Il est indicateur de la qualité de l'inventaire effectué (est-ce qu'on a atteint un plateau ou non en termes de nombre d'espèces au fil des sessions).

Je "pose ça là", pour avoir ici les avis, idées, propositions de chacun, et voir si d'autres utilisateurs de GeoNature seraient intéressés pour participer au projet. Pour notre part on peut faire les CCTP, mettre les mains dans le cambouis pour la base de données. Coté interface en revanche on ne pourra rien faire. Si personne d'autre n'est intéressé on se contentera, je pense, de brancher QGIS à notre instance pour l'utiliser en guise de module de saisie! En effet, pas de budget possible pour ce projet là.

[gildeluermoz]

Yes enfin ! Qq remarques.

• Y'a pas une notion de rang d'observation des taxons dans le chronoventaire : 1er, 2ème, 3ème, etc.?
• Comme le mobile serait un vrai plus pour ce genre de protocole, je trouve que les infos d'occtax sont trop complètes. Il faut simplifier et si les champs d'occtax sont conservés pour le standard, il faut en mettre l'essentiel avec des valeurs par défaut.
• Le dénombrement fait-il réellement partie du protocole ? En tout cas de ce que j'en avais compris non (ou pas dans tous les cas). A t-on le temps de réaliser un dénombrement dans un chronoventaire ? Avec quelle validité ? Peut-on le traiter dans l'analyse des résultats ?

En première approche je simplifierais fortement le modèle pour ne retenir que les champs réellement utiles au protocole. Ensuite, lors du passage en synthese via des triggers, une table des valeurs par défaut permettrait de rendre paramétrable cette compatibilité avec le standard. On peut imaginer ici que ces valeurs par défaut soient différentes d'un jeu de données à l'autre.

[DonovanMaillard]

Salut,

• La notion de rang observation ressort par la session au cours de laquelle l'espèce a été vue, on ne note pas espèce par espèce son rang d'apparition.
• Le mobile serait en effet intéressant, mais j'avoue que pour le moment je n'ai pensé qu'à la version web (on aura ni les moyens ni les compétences d'envisager le mobile dans notre cas donc je reste simple pour l'instant).

Un certain nombre de champs sont en effet à simplifier, celà dit meme dans le cadre du protocole, ca reste intéressant de connaitre la méthode de détermination ou ce genre de choses. La naturalité, l'état biologiques, les preuves, la méthode etc peuvent être masqués par défaut avec une valeur attribuée , mais à mon sens conserver un "sample_number" peut être intéressant pour ce qui n'est pas identifiable à vue.

• Le dénombrement ne fait pas partie du protocole 'officiel'... pour l'instant. Rien n'est planifié mais d'après Yann ca fait partie des évolutions possible du chronoventaire officiel. Mais plus honnêtement, ma proposition qui intègre le dénombrement (à mettre en paramètre à la limite) est basée sur notre manière un peu modifiée d'appliquer le protocole, et sur le fait que toute cette partie peut être simplement dupliquée d'occtax donc facile à mettre en oeuvre :

Flavia devrait publier dans quelques temps une déclinaison du protocole qui apporte des réponses bien plus précises sur les cortèges d'espèces. On a décliné le chronoventaire en 'chronocapture' (enfin... ils ont décliné, moi j'ai trouvé le nom et j'imagine le module): On capture les bêtes sur le site et on ne les relache qu'à la fin de l'inventaire, pour faire un dénombrement complet des individus de chaque espèce, sans remise des papillons sur le site entre chaque session. On a donc le temps de dénombrer correctement, et ca permet dans le résultat de voir si en effet le rang/abondance se vérifie, de voir si une espèce est caractéristique du milieu (présente à plusieurs sessions) ou simplement de passage (1 obs), de voir les abondances relatives et une abondance totale sur le site. Ca comble un biais du protocole qui fait qu'une espèce très détectable peut etre vue en premiere session sans pour autant etre abondante... ou l'inverse avec plein de petits papillons marron sur une végétation cramée).

Ce n'est pas le protocole officiel, mais il est plus informatif et, puisqu'il a le même fonctionnement par session, peut se calquer sur un module chronoventaire dès lors que le module permet de conserver cet aspect dénombrement. En revanche dans ce cas, c'est toujours des individus, qui sont toujours comptés, et toujours des imagos. Donc le dénombrement se limiterait à un compte (pas de min et max). De mémoire pour notre part on note pas le sexe mais à voir si ca peut etre une info à conserver ou non. Ce protocole est intéressant dans le sens où il serait à tester sur les orthoptères, sur la malaco, éventuellement les coléos etc.

A rediscuter donc car on tord le cou au protocole, mais avec tout ce qui est masquable, je pense que garder un dénombrement (un compte + un éventuel sexe si ça intéresse du monde, masquable eventuellement en conf) permettrait d'avoir quelque chose de très allégé quand même en interface. D'ailleurs la saisie se fait actuellement sur papier, avec un simple tableau de contingence : espèce /nombre/session, le nombre d'info à relever reste donc limité.

C'est totalement hors sujet, mais le protocole gagnerait à être testé sur les orthoptères, les mollusques, les coléos éventuellement, voire pourquoi pas la bota ou les lichens.

[DonovanMaillard]

Coté interface, je ferai rapidement des montages pour partager la manière dont j'imagine le module, ca fait un moment que ca me trotte dans la tête :)

[Amegilla]

Bonjour,

Ce module est aussi attendu en Occitanie ! Des news à ce sujet ?

[DonovanMaillard]

Salut Romain,

Fait pour notre part mais via le module monitorings développé par Joel et Amandine au PNC.

Dans leurs dépot il y a des exemples de protocoles (cf doc du module monitorings), j'ai fait une PR avec toute la conf pour le module chronoventaire (qu'on appelle chronocapture on a un peu modifié la méthodo) https://github.com/PnCevennes/protocoles_suivi/pull/1/files

Dans tous les cas c'est à 95% la même méthode et tu n'auras rien ou presque à faire pour le transformer en chronoventaire. Je dois faire une petite mise à jour pour les datasets, Joel a amélioré ce point depuis que j'ai fait le module, pour le reste tout fonctionne chez nous.

[Amegilla]

OK top, je vais regarder tout ça. Merci pour ta réponse rapide !

[laurentbarthe]

Bonjour. Nous attendons avec impatience ces modules qui vont rénover et faciliter la saisie et la gestion des données. Merci à ceux qui prennent l'initiative de faire de tels développement. Ça serait vraiment utile qu'on puisse avoir accès facilement à des modules finalisés dans les prochaines mises à jour pour valoriser rapidement auprès des utilisateurs qui sont demandeurs.

[DonovanMaillard]

@laurentbarthe le module monitorings a eu une première release stable fin juin : https://github.com/PnX-SI/gn_module_monitoring/releases/tag/0.1.0

Il est donc installable comme d'autres modules (export par exemple, import mais à attendre un petit peu, une 1.1 va arriver rapidement) et déjà valorisable auprès des utlisateurs.

Le module monitorings est adapté pour des suivis, nous utilisons le chronocapture (proche du chronoventaire) dans le cadre de suivis dans notre cas, c'est pour ca que nous avons utilisé ce module. Si vous utilisez le chronoventaire pour de l'inventaire calibré mais occasionnel, sans repasser sur un panel de sites donné à plusieurs reprises, notre solution ne peut effectivement pas convenir.

Le module monitoring est fait pour que chacun puisse y configurer ses propres outils de saisie dans un cadre du type :

• Je dispose d'un panel de sites
• J'y effectue différentes visites
• Chaque visite fait l'objet de tel ou tel relevés d'informations.