[CMR] - Gestion des individus dans monitoring ?

[DonovanMaillard]

Bonjour,

Dans le cadre de ses missions, la SHF a commencé à travailler sur un module CMR qui a donné lieu à des premières briques.

A revoir en détail ce qui est fait, il ressort que les besoins de la CMR et du Monitoring sont extrêmement proches et avoir 2 modules distincts n'est pas nécessairement pertinent à mon sens... La différence principale entre monitoring et CMR consiste en la gestion d'une "banque" d'individus, avec ses informations dédiées, certaines génériques (à intégrer en dur), d'autres spécifiques (à intégrer dans des champs jsonb comme c'est le cas aujourd'hui dans monitoring). Puis une correspondance entre individus et modules.

Toute la logique d'avoir des sites, comportant des visites, et faisant l'objet d'observations, est conservée dans les deux modules. Avoir deux modules distincts embarquant ces portions de code n'est donc pas souhaitable.

Organisation Certains éléments centraux du module monitoring (t_sites, t_visites, t_observations etc) sont déjà intégrés au coeur de GeoNature. Si ce n'est pas encore le cas il serait pertinent de pousser également dans le coeur de geonature toutes les routes pouvant être génériques sur ces tables là, afin qu'elles puissent servir à plusieurs modules.

Dans la même logique, la notion d'individus et les tables/routes nécessaires devraient être traitées également dans le coeur de GeoNature pour pouvoir servir à différents modules.

A partir de ce moment là, les sites, visites, observations et individus peuvent être utilisés par différents modules, et se pose donc la question d'avoir un module CMR spécifique, ou d'intégrer la notion d'individus au module monitoring.

Définition actuelle des individus Actuellement, les individus sont définis par quelques variables en dur

• id (technique)
• uuid
• identifiant (métier)
• rfid
• marque
• sexe
• cd_nom
• commentaire
• data jsonb

A mon sens, RFID ne devrait pas être en dur. Sex devrait être soit pas en dur, soit nommé "id_nomenclature_sex" . A l'inverse on pourrait ajouter en dur l'id ou le nom de la personne qui a procédé au marquage et la date de marquage qui sont des infos constantes quand on marque des individus.

En interface, il y a donc un onglet "individus" en plus de l'onglet sites, et une fiche individus qui pourrait être rendue générique (pas suffisamment le cas dans les développements initiés).

Module CMR ou étendre le module monitoring ? A mon avis, redévelopper toute la logique aire de sites, sites, visites, observations, méthodes de configuration en json etc est discutable tant les deux modules sont proches in fine.

Je serais plutôt favorable à avoir une brique "individus" optionnelle dans le module monitoring, que chaque sous-module appelle ou non selon les besoins de chaque protocoles. Une configuration individuals.json permet de définir le formulaire des individus comme pour les autres niveaux. Dans la configuration du sous-module, on pourrait ajouter le niveau "individual" sous les observations, qui déclencherait l'affichage d'un onglet "individus" et l'appel aux routes correspondantes.

Des avis sur la question ?

[camillemonchicourt]

Pour moi la partie BDD du Monitoring (BDD, modèle et routes) a sa place dans le cœur de GeoNature et c'est comme cela que ça été conçu initialement. Ensuite le module MONITORING a ajouté quelques éléments de BDD dans le module, mais cela a vocation selon moi à basculer dans le cœur de GeoNature.

Selon moi, il en est de même avec le concept d'individus qui devrait être central et transversal en étant intégré dans le cœur de GeoNature.

Rien n'empêche ensuite un module de s'appuyer sur les éléments centraux de gn_monitoring sans les dupliquer, et idem si on y ajouter les éléments liés aux suivis d'individus.

Ensuite à savoir si les suivis d'individus doivent être un module à part, ou si ils peuvent être ajoutés dans le module MONITORING, je penche sur la 2° solution sans avoir d'avis tranché. Dans tous les cas, ils ne devraient pas dupliquer les tables des sites, visites, observations et individus fournies par GeoNature.

En regardant le SQL du module CMR qui a été développé, il ne semble ajouter que ses tables liées au CMR - https://github.com/PnX-SI/gn_module_cmr/blob/master/data/cmr.sql Ici il y a un MCD qui semble le confirmer mais ne parait pas à jour - https://github.com/PnX-SI/gn_module_cmr/blob/master/docs/MCD_CMR.jpg

En amont, il faut en effet bien définir les champs génériques qui définissent un individu et un CMR.

[DonovanMaillard]

Je n'ai pas connaissance de ce dépôt, je me base sur ce qu'avait fait geofit et que j'ai installé en local. Sur lequel j'ai bien un schema gn_cmr et uniquement 2 tables dédiées aux individus. Le module cmr commencé dessus fonctionne pour la partie BDD, c'est l'interface essentiellement qui ne va pas.

[MathRdt]

Hello, Je voulais savoir quelles étaient les prochaines étapes/échéances sur cette question et si nous (le CREA) pouvions contribuer à cette évolution ?

Y a t'il des pré-requis qu'il faudrait terminer avant d'aborder le sujet ? (Gestion des permissions sur le module monitoring ?)

[camillemonchicourt]

Salut, assez partant pour que ça soit dans le cœur de GeoNature en complément de gn_monitoring. Mais avant tout, il faut préciser ce que l'on souhaite faire et gérer, et modéliser tout ça. C'est la première étape.

[DonovanMaillard]

Je vais vous faire suivre le modele pour la partie individus, en intégrant les modifications qui me semblaient nécessaires par rapport à l'existant. Je tente de faire ça rapidement :)

[ColinVanReeth]

Salut, est ce que tu t'en sors @DonovanMaillard ? Dis nous si on peut t'appuyer d'une façon ou d'une autre. On a une grosse force de frappe en ce moment avec @MathRdt ;)

[camillemonchicourt]

Pas certain, mais je pense que ce qui est le plus à jour mentionné par Donovan est ici - https://github.com/FlorentRICHARD44/gn_module_cmr/blob/cmr_cistude2/data/cmr.sql

Par pour autant que c'est ce qui est bien...

Mais dans tous les cas, on a la base.

• Une table des individus
• Une clé étrangère vers l'individu renseignable dans la table des observations (table existante dans gn_monitoring à laquelle il faut ajouter une clé étrangère vers id_individual

Plus en détail, @DonovanMaillard indiquait au sujet de la BDD actuelle du CMR :

_LIENS ENTRE INDIVIDUS ET AIRES D’ÉTUDES

Actuellement, la base de données établit déjà une correspondance entre un individu et un sous-module (=protocole). De ce fait, l’évolution proposée de ne plus obligatoirement filtrer les individus par aire d’études n’entrainerait pas d’évolutions sur la base de données en elle-même. Elle renforce cependant la proposition, puisque les individus sont bien rattachés à un sous-module et non pas à une aire en termes de stockage de l’information.

STOCKAGE DES INFORMATIONS SUR LES INDIVIDUS

Afin de répondre à un maximum de besoins, la base de données du module comporte plusieurs tables, disposant de champs « vrais » et de pseudo-champs au format json (data). C’est notamment le cas de la table t_individual, dont la structure pourrait être améliorée.

Actuellement, certains champs « vrais » (ou « en dur ») pourraient être supprimés - tels que le sexe ou le code rfid - puisque selon les protocoles ces informations peuvent ne pas être relevées. Ce changement de stockage n’impacterait en rien la saisie ni la disponibilité de l’information pour l’utilisateur, puisque ces données pourraient être stockées dans le pseudo-champs configurable et propre à chaque sous-module, mais cela permettrait de ne pas les imposer pour tous les sous-modules (=protocoles).

A l’inverse, des informations génériques pourraient être ajoutées, comme la ou les personnes qui ont effectué le marquage ou encore la date de marquage, qui sont des informations pertinentes pour tous les protocoles de type CMR (même si ces champs ne sont pas rendus obligatoires lors de la saisie)._

Je suis d'accord sur la partie concernant les individus. Il faut bien identifier les infos génériques pour tout type d'individus et de protocoles et celles spécifiques à gérer dans un champs json.

Concernant le lien entre les individus et les protocoles (sous-modules), il y a en effet un champs id_module dans la table t_individual. Mais il y a aussi une table cor_individual_module qui selon moi est donc redondante.

Mais j'aurai tendance à privilégier cor_individual_module car selon moi un individu peut être suivi dans plusieurs protocoles (sous-modules), non ?

A discuter et affiner.

Mais à voir aussi côté CREA comment vous voyez la partie BDD et quels sont vos besoins ?

[ColinVanReeth]

Ok merci pour les infos. Côté CREA, il n'y a pas de besoins supplémentaires. Est ce qu'on se prévoit une visio pour traiter les différents points à discuter/trancher ? Vu que les évolutions touchent au coeur de GN, est ce que vous voulez le gérer côté PNE ? si oui quelles seraient vos échéances ? De notre côté, on aurait aimé mettre en ligne notre programme utilisant le futur module CMR cet été, mais à voir en fonction de notre organisation collective

[camillemonchicourt]

Nous n'aurons pas la capacité à réaliser ce développement de notre côté, seulement de l'accompagner.

Il faut valider un modèle de données, réaliser une migration Alembic pour créer les tables en question puis ajouter la partie modèles, backend et API. Dans GeoNature.

[ColinVanReeth]

OK entendu. avec @mathieu-roudaut-crea on va avancer sur le modèle des données d'ici juin, et si c'est OK pour vous, on se lance cet été dans les devs

[mvergez]

Bonjour,

Natural Solutions a été choisie pour l'implémentation de la notion d'individus dans monitoring.

Voici, dans les grandes lignes, ce qu'il est prévu de faire :

• Création d'un nouveau fichier individuals.json (optionnel) et possibilité de l'ajouter dans l'arbre du fichier config.json
• Ajout d'une colonne nullable id_individual dans t_observations
• Ajout d'un système (via Trigger ou via change si possible) pour affecter le cd_nom dans t_observations en fonction de l'individu
• Ajout de nouvelles tables t_base_individuals, t_individual_complements et cor_individual_module (voir schéma ci-après)
• Ajout d'un nouveau modèle dans definitions.py a l'instar d'observation_details
• L'objectif est de pouvoir créer des individus et de les mentionner pendant l'observation. Plusieurs possibilités :
  • Ajout depuis l'onglet "Individus" situé au même niveau que les groupes de sites et les sites
  • Ajout d'un nouveau widget qui permet soit de sélectionner soit de créer un nouvel individu durant l'observation (nous préciserons le fonctionnement dans un second temps)
  • Ajout d'un flask admin (ne sera pas fait)

N'hésitez pas si vous avez besoin d'avantage de détails, je ne voulais pas détailler tout ici au premier abord.

En espérant que cela vous convienne !

[amandine-sahl]

Super analyse merci, Par contre je me pose une question sur le marquage des individus et la temporalité. En fonction des espèces un même individus peut avoir plusieurs marques voir type de marquage (peinture, décoloration alaire, bague, ...). En fonction du type de marquage les informations ne sont pas forcement les même. Est-ce que la representation actuelle est suffisante?

[mvergez]

Merci pour ton retour @amandine-sahl ! A voir mais peut-être que juste un formulaire "dynamique" avec des conditions hidden pourrait faire l'affaire dans ce cas là. Il sera possible également de faire évoluer le modèle si besoin mais cela ne fera pas partie de cette prestation

[camillemonchicourt]

Si le modèle doit être ajusté, il faut le faire avant d'implémenter un premier modèle et des développements associés.

[DonovanMaillard]

Bonjour,

On est en train de regarder avec NS la faisabilité - en restant dans le devis déjà établi - de modifier le MCD pour splitter la table t_individuals du modèle ci-dessus en 2, afin de dissocier les informations d'individus et de marquage.

Dans le cadre de cette prestation, on se limitera à splitter la table en deux, et faire un héritage avec une relation 1-1 : on pourra donc à l'issue de ces développements saisir comme prévu initialement 1 indivu = 1 marquage = un unique formulaire de saisie. Mais le splittage de cette table permettra à termes de configurer 2 formulaires (individu + marquage), et de mettre en place une relation 1-n : un individu pourra avoir plusieurs marquages, éventuellement de plusieurs types différents. On pourra même envisager à terme de filtrer les individus en fonction de leurs marquages pour identifier plus facilement l'individu que par leur simple "code".

Le nouveau MCD serait donc :

Si @mvergez valide la faisabilité sans que ça demande trop de temps, on partira donc sur un fonctionnement 1-1 avec un schéma déjà prévu pour une évolution 1-n dans un second temps par qui pourra le faire ou le financer. Si ce n'est pas possible, les CCTP et devis étant déjà validés, la mission se poursuivra comme elle était initialement prévue, une migration devra alors être prévue dans un second temps.

Pour le moment le tout sera dans le schema gn_monitorings (installé par le coeur de GeoNature). Un schéma gn_individuals pourra être envisagé quand on disposera d'un "vrai" module individus au délà du cadre du monitoring.

[mvergez]

Merci beaucoup @DonovanMaillard pour toutes ces informations.

Pour la faisabilité je pensais faire un héritage des objets ORM dans ce sens : TBaseIndividuals > TMarkingEvents > TIndividualComplements

Je pense faire comme ça car on est obligé d'écrire tout l'objet depuis le front c'est à dire les propriétés de base de t_base_individuals, les propriétés de t_marking_events et en plus les propriété additionnelles de t_individual_complements.

Je vais quand même vérifier que ce double héritage fonctionne bien du point de vue ORM

Néanmoins, cela vous convient-il ?

[DonovanMaillard]

@amandine-sahl est-ce que ce fonctionnement conviendrait pour les évolutions que tu envisagerais ensuite ?