Redistribution des besoins métiers dans GeoNature - Saisie, édition, consultation, validation

[AJambon]

Bonjour,

Dans le cadre d’un projet avec Picardie Nature, nous sommes actuellement en pleine réflexion sur l'organisation des fonctionnalités dans GeoNature notamment entre les modules de synthèse, occtax et validation.

L'origine de cette réflexion :

Comment modifier des données provenant de différentes sources au même endroit et répercuter ces modifications jusqu’à la source (occtax, monitoring, import, citizen) ?

Par exemple, OccTax sert aujourd'hui de module de saisie mais également de consultation et d'édition. Les données de ce module sont également consultables dans la synthèse, ce qui fait doublon.

Pour les données issues de l’import : elles sont uniquement consultables dans la synthèse mais non éditables, même pour les données sources.

Une solution que nous voyons :

• Que la consultation soit uniquement l'objet du module de synthèse.

• Que la saisie se fasse dans les modules et applications dédiées : monitoring, occtax, import et citizen

• Que l'édition se fasse via un module qui permette l'édition d'une donnée de n'importe quelle origine. Or, d’après l’expérience que nous pouvons avoir sur d’autres plateformes et les besoins métier, cette fonctionnalité d’édition nous semble être reliée à la gestion de la validation. Ainsi, le module de validation pourrait être renommé et constituer le module d’édition/validation.

Ce que ça changerait :

• Le module occtax pourrait alors être simplifié en un module uniquement de saisie, avec une arrivée seulement sur une carte et en enlevant la liste des observations (redondante avec la synthèse).

• Le module de validation serait un module de validation et d'édition de la donnée. Cette donnée serait donc éditée et ses valeurs historisées. La fonctionnalité de validation serait paramétrable et donc activable ou non. Les personnes n’ayant pas de droits de validation pourront donc éditer uniquement leurs données et signaler toutes données leur semblant douteuses.

• La synthèse ne changerait pas et afficherait donc toutes les données à leur état actuel.

N'hésitez pas à partager vos avis sur cette réflexion !

Bonne journée,

L'équipe GeoNature de Natural Solutions

[DonovanMaillard]

Bonjour,

Par nature, les modules produisent des données qui ont des formats et origines qui leur sont propres. Et qui par ailleurs possèdent leurs propres permissions.

Ainsi, si un utilisateur 1 a les droits sur Occtax mais pas sur Validation, comment pourrait-il modifier ses données?

Pour moi, la saisie et l'édition restent très liés : mêmes formulaires, mêmes origines des données donc même module. La question pourrait davantage se poser au niveau de l'export, mais là aussi, chaque module disposant de ses propres spécificités et formats,il reste intéressant de pouvoir exporter les données sources complètes au sein du module. La synthèse est là pour exporter uniquement les données de synthèse, donc les champs génériques communs à un maximum de modules. Avec le jsonb "champs additionnels" de la synthèse,ça change un peu la donne et il y a peut être en effet un "dédoublonnement" à voir de ce coté.

A voir, mais c'est une proposition qui touche la structure même et la logique dans lesquels GeoNature a pris ses racines. Un module pour saisir et un autre pour éditer une même donnée par exemple ne me semble pas du tout intuitif.

Concernant l'import, le choix a été fait de ne pas pouvoir modifier les sources (par définition il sert a importer des données d'autres outils/partenaires), mais ce choix peut être discuté selon les cas.

[Adrien-Pajot]

Salut,

Pour le coup je trouve que cette idée est plutôt très cohérente avec le modèle actuel de GeoNature : séparation des besoins métiers au sein de GeoNature. Modèle que l'on retrouve dans bien des applications d'ailleurs (comme Biolovision ou eBird, utilisés par des millions de personnes).

Ainsi, si un utilisateur 1 a les droits sur Occtax mais pas sur Validation, comment pourrait-il modifier ses données?

Le module étant un module d'édition, tout utilisateur aurait accès au module d'édition mais n'aura pas forcément les droits de validation, ce qui est différent. Cela pourrait devenir un module coeur.

Pour moi, la saisie et l'édition restent très liés : mêmes formulaires, mêmes origines des données donc même module.

Prenons le cas où je suis responsable de ma base. En plein hiver, je veux nettoyer ma base, je vais aller me taper 4 modules ou outils différents (occtax, import, citizen, monitoring) pour faire la même action : éditer et corriger des données. Ce qui n'est pas très cohérent puisque les informations sont globalement les mêmes sauf champs additionnels, et que justement les champs à modifier sont souvent les champs principaux (x, y, cd_nom, date, t_role).

La question pourrait davantage se poser au niveau de l'export, mais là aussi, chaque module disposant de ses propres spécificités et formats, il reste intéressant de pouvoir exporter les données sources complètes au sein du module.

Là je te rejoins, bien que si tu ajoutes dans le module synthèse un filtre "module d'origine des données" tu retrouves toutes tes données par source et tu fais ton export ?

A voir, mais c'est une proposition qui touche la structure même et la logique dans lesquels GeoNature a pris ses racines. Un module pour saisir et un autre pour éditer une même donnée par exemple ne me semble pas du tout intuitif.

Je n'ai pas ton expérience sur GeoNature mais pour le coup je croyais justement que la force de GN venait de sa modularité et de la séparation des besoins métiers. La validation d'une donnée ? L'export de celle-ci ? Pourquoi ne pas tout mettre dans OccTax dans ce cas ? Pour le coup étant sur pas mal d'outils, je trouve ça bien plus intuitif de séparer les actions.

Concernant l'import, le choix a été fait de ne pas pouvoir modifier les sources (par définition il sert a importer des données d'autres outils/partenaires), mais ce choix peut être discuté selon les cas.

Oui en effet, l'édition/validation ne doit pouvoir s'effectuer que sur les données sources. Bien que des données historiques (et bientôt des données de protocoles ?) puissent être importées via ce module et donc appartenir à la structure ?

Bien que ce soit un changement léger de structure, je pense qu'il est vraiment intéressant et permettra une UX plus intéressante. Je me connecte à GeoNature pour Saisir et/ou Editer et/ou Consulter et/ou Exporter et/ou Importer etc.

[DonovanMaillard]

Oui mais les outils que tu vises ne font que de la donnée opportuniste sauf erreur. Là, l'approche prise est de s'orienter dans l'outil en fonction du type de données sur lesquelles on travaille.

Données opportunistes -> Occtax Méthodes de suivi -> Monitoring Habitats/Milieux -> OccHab etc

J'ai du mal à voir la faisabilité / lisibilité pour l'utilisateur d'aller saisir une donnée dans différents modules (la saisie ne pourra pas se faire dans un unique module) mais d'aller les éditer toutes au même endroit.

Pour l'import en effet, il est suscepitble d'évoluer vers un module de données "externes" mais qui viennent de la structure et qu'on peut vouloir éditer ou non. C'est pas le besoin pour lequel il a été pensé et il faudra qu'il puisse répondre correctement au besoin initial mais oui, il peut évoluer pour apporter des réponses plus larges.

J'aurais un point de vue un peu différent quand même du votre, laisser la saisie et l'édition ensemble pour conserver l'approche "un type de donnée = 1 module" et techniquement, garder les formulaires, structures, types d'info etc au même endroit. Mais peut-être que réserver l'export à la synthèse simplifierait les modules en effet (d'autant que dans la pratique, je pense que l'essentiel des utilisateurs passe par la synthèse pour tout export, sans chercher le module d'origine).

[AJambon]

Merci pour ton avis Donovan !

En effet la proposition peut paraitre tout remettre en question et peut changer des habitudes. Notre but est vraiment de rendre l'outil le plus intuitif et facile d'utilisation possible.

Je n'ai pas été beaucoup dans les détails de la raison pour laquelle nous avons abouti à cette proposition, ça permettra peut-être de mieux comprendre notre cheminement de pensée et d'aboutir à la solution qui contentera le maximum d'utilisateurs tout en étant le plus logique au niveau de l'outil.

La demande initiale de Picardie Nature concerne des améliorations du module de validation. Parmi ces améliorations, une demande de permettre aux validateurs de modifier des données directement dans le module de validation. En effet, il est actuellement possible de modifier une donnée dans le processus de validation mais en accédant à chaque module, ce qui est plutôt lourd (sans parler du cas citizen). Une première idée est donc de pouvoir modifier les données dans le module de validation en répercutant ces modifications dans chaque module. Cette option ne nous convenait pas car engendre beaucoup de complexité dans le dev et renforce des liaisons entre les modules ce qui va à l'encontre de l'architecture modulaire de GeoNature. C'est dans ce contexte que nous avons réfléchi à la proposition précédente :)

[Adrien-Pajot]

Oui c'est ce qu'on discute côté NS, et justement c'est ce qui devient complexe en effet.

Quand on voit OccTax et ses données d'occurrences aléatoires (souvent plus de 90% de celles de la structure non ?) on a une volonté de séparer les besoins métiers. Pour le coup les données de Monitoring, et celle de l'import génèrent des occurrences (protocolées) aussi.

Je pense qu'on peut envisager d'y aller progressivement : pour l'instant quand tu édites ou valides une donnée tu édites ou valides une occurence de taxon (occurrence aléatoire ou protocolée) et ne change que les informations de la synthèse. Par contre demain, quand tu veux aller modifier des données protocolées, tu accèdes à tout ce qu'il y a autour de l'occurence, comme pour OccTax d'ailleurs, ce qui facilite la vie. Sinon, si tu as 10 protocoles, tu dois rentrer dans chacun et valider chaque site puis chaque donnée au cas par cas, ce qui rend la vie du gestionnaire de base complexe ?

Je pense que "l'approche "un type de donnée = 1 module" montre ses limites dès que l'on fait plusieurs métiers par type de données. La preuve avec la synthèse qui te permet de tout consulter, le module d'export de tout exporter, le module d'import qui ira dans différentes sources, le module de validation qui te permettra de valider différentes sources etc etc. ?

Mais peut-être que réserver l'export à la synthèse simplifierait les modules en effet (d'autant que dans la pratique, je pense que l'essentiel des utilisateurs passe par la synthèse pour tout export, sans chercher le module d'origine).

En effet, je te rejoins là-dessus.

[bouttier]

Bonjour, Il me semble également compliqué d’avoir d’une part des modules dédiés à un type de données, et en parallèle un éditeur capable de supporter l’ensemble de ses types de données. D’autre part, qu’un module comme OccTax permette à la fois la création et l’édition d’une donnée ne me semble pas si compliqué, car comme le disait Donovan, l’ensemble des formulaires peuvent être réutilisé, c’est un pattern assez classique. Je serais donc curieux de savoir techniquement comment un module d’édition commun pourrait être implémenté : comment les modules sont découverts ? comment leur données sont accédées ? etc.

[Gaetanbrl]

Bonjour,

D'après ma compréhension du modèle, de l'interface GeoNature (+ des modules) et de la complexité des devs que demande la centralisation des saisies dans le module de validation, est-ce qu'il ne serait pas possible de proposer des liens ou raccourcis vers les modules adéquates pour modifier une occurence depuis le module de validation ?

C'est déjà le cas avec le bouton "Voir l'observation dans le module de saisie" et ca permet de conserver le fonctionnement 1 type de données = 1 module.

D'un point de vue expérience utilisateur, l'environnement de validation me semble propre au contrôle, à l'échange entre validateurs et à la validation (ou non) des observations. Si il est possible de faire de l'édition dans la validation, alors ce module de validation n'est plus un module de validation mais de gestion des observations qui se complexifie. D'un point de vue architecture, sa position en tant que module n'a donc plus lieu d'être et il serait préférable d'en faire un module coeur comme pour la synthèse.

Donc pour moi la saisie doit rester indépendante de la validation car elle est accessible pour un observateur (pour ses saisies) et un validateur.

Je suis par contre d'accord que l'affichage dans le module de validation est à revoir et avec une revue de l'ergonomie. Si on y ajoute de façon intelligente l'ajout de raccourci vers les modules de saisie (avec les bons libellés pour bien comprendre ce qu'on réalise) ca faciliterai déjà pas mal le boulot des profils multi métier / validateurs non ?

[Gaetanbrl]

@AJambon si les fonctionnalité de saisie de OccTax, Citizen, Monitoring sont centralisée dans une interface, il faut aussi centraliser la saisie des OccHab pour garder une cohérence et ne pas avoir une saisie centrale pour 3 module et une saisie ailleurs pour un autre.

J'ai peur dans ce cas que ce type d'interface soit vite complexe à comprendre (et à réaliser). Par expérience, on sait que quand on met des utilisateurs devant un module de saisie / édition qui touche à plusieurs modèle, ils sont vite perdus (qu'est-ce que je saisi ? qu'est-ce que je vois ?). Ca demande une attention particulière pour organiser l'interface et bien diriger les utilisateurs.

Donc au final... la séparation des éditions / modification par type de données c'est peut-être pas si mal, notamment quand un profil n'a qu'un métier.

[camillemonchicourt]

En effet, ce ticket aborde des constats partagés. Notamment la confusion potentielle entre Occtax et Synthèse et l'idée de recentrer le module Occtax sur la saisie/édition de SES données, et privilégier les recherches et export dans la Synthèse. Mais aussi le fait que certaines données sources dans GeoNature sont difficilement modifiables, ou seulement en passant par la BDD (Données venant du module Import notamment).

Cependant il nous parait important de garder la logique structurelle de GeoNature, où l'on a différentes sources de contenus, correspondant à différents contextes (protocoles, partenaires, historiques...) et toute leur richesse et éventuelles spécificités.

La synthèse remet à plat le tronc commun entre toutes les observations provenant des différents contextes et protocoles, en mettant de côté leurs spécificités. L'idée conceptuelle de la synthèse est qu'elle ne stocke aucune info mais est recalculable à n'importe moment. C'est pourquoi pour les infos génériques et globales comme l'historisation, les médias, la validation...) on ne stocke les infos ni dans la source ni dans la synthèse mais dans ce que l'on a appelé des tables transversales mobilisables par la source comme la synthèse (https://github.com/PnX-SI/GeoNature/issues/339).

Il nous semble ainsi très important de ne pas faire des modification directement dans la Synthèse car celles-ci ne seraient pas répercutées dans la source et pourrait apporter de l'incohérence dans les données.

Il ne me semble pas non plus pertinent de centraliser un module de modification de données. Saisir une observation aléatoire dans Occtax ou un suivi d'une espèce dans Monitoring dans le cadre de la visite d'un site dans un protocole bien particulier sont des choses bien différentes. Sans parler des autres modules et protocoles de suivi comme "Suivi-Flore-Territoire" ou encore "Suivi-Habitat-Station". De plus les formulaires de leurs modules ont été travaillé sur mesure pour bien répondre à leur besoin et contexte de saisie. Modifier une observation provenant d'un protocole du module Monitoring en la décontextualisant de sa visite et de son site me parait risqué et pas clair pour l'utilisateur.

Mais cette question de pouvoir modifier facilement des erreurs de taxons globalement, et de bien répercuter la correction dans les différentes sources où un taxon a été mal identifié reste entière...

Pour le retour à la source depuis la Synthèse ou le module Validation, en effet la table gn_synthese.t_sources sert à faire ce lien entre une occurrence dans la Synthèse et son origine dans la table source.

[Gaetanbrl]

Sans parler des autres modules et protocoles de suivi comme "Suivi-Flore-Territoire" ou encore "Suivi-Habitat-Station".

@camillemonchicourt La question se pose également si demain un nouveau module est développé par un organisme indépendant pour des données particulières (ex au hasard : biodiversité marine). Le module intégrera potentiellement des critères spécifiques et un modèle différent qui intégrera son propre mode d'édition / modification des données. Il y aura alors toujours une vue par module pour la modification des données et le problème de multi endroits pour la saisie se posera encore...

Ce qui peut être intéressant et c'est une solution que je propose, c'est de pouvoir ajouter facilement des lien (routes) d'un module x (e.g validation) vers un autre module (via une config ou un petit dev en plus) et de prévoir dans les modules la possibilité d'accéder à une ressources à partir de l'UUID. Ca reste souple et je pense plus accessible qu'une modification de toute la structure VMC GeoNature.

En revoyant l'UI de la modal Synthèse / Validation on peut ajouter une suite de bouton / raccourci / outils pour ce type d'actions sans tout remettre en question.

[camillemonchicourt]

Oui c'est justement le cas pour "Suivi-Flore-Territoire" ou encore "Suivi-Habitat-Station" qui sont des modules de protocoles développés par un organisme particulier.

Si j'ai bien compris ce que tu évoques, c'est bien déjà le cas. Si tu renseignes bien table gn_synthese.t_sources avec le champs url_source alors tu auras automatiquement un lien vers la fiche de l'objet dans son module source depuis la liste ou la fiche détail d'une occurrence dans les modules "Synthèse" et "Validation".

C'est comme ça que le lien est généré depuis Synthèse et Validation vers la fiche détail d'une observation dans le module Occtax :

[Gaetanbrl]

C'est comme ça que le lien est généré depuis Synthèse et Validation vers la fiche détail d'une observation

C'est bien ce fonctionnement que j'avais en tête @camillemonchicourt ;)

Merci pour les détails techniques, ca aide à bien voir le fonctionnement.

[AJambon]

En effet cette réflexion engendre beaucoup d'autres éléments qui ont été abordés dans les différentes réponses et qui nous avaient menés à l'initiation de l'issue. Le meilleur compromis semble dans un premier temps de garder l'édition uniquement dans le module source de la donnée (redirection à partir du module de validation).

La grosse réflexion sous-jacente semble concerner la structure des données : pouvons-nous identifier un socle commun entre les données d'occurrence et les données protocolées ? L'occurrence peut-elle constituer une brique élémentaire de la donnée comme le suggère le standard SINP ? Dans ce cas la structure de la BDD de GeoNature pourrait être revue pour stocker les occurrences dans une même table quelque soit le module de provenance. Dans ce cas la BDD monitoring permettrait le stockage des données de contexte de l'occurrence. Cette réorganisation permettrait une édition/validation centralisée de la partie commune = occurrence. Cependant, établir ce socle commun présente quelques limites qui doivent être résolues à la fois dans les outils et à un niveau plus global.

Même si cela reste encore hypothétique, l'amélioration du module validation s'appuiera sur ces réflexions et vos avis, si nous sommes à l'origine des développements.

[DonovanMaillard]

L'occurrence peut-elle constituer une brique élémentaire de la donnée comme le suggère le standard SINP ? Dans ce cas la structure de la BDD de GeoNature pourrait être revue pour stocker les occurrences dans une même table quelque soit le module de provenance.

Oui et non... c'est ce que fait pour partie la synthèse, en reprenant les infos les plus communes/transversales à la majorité des données naturalistes. Mais nombreux de ses champs sont facultatifs, et peuvent ne pas être pertinents dans certains protocoles. Et surtout dans bien des protocoles, l'occurrence n'est pas la clé d'entrée la plus pertinente (voir cmr avec les individus/sites en entrée, voir modules habitats, voir monitoring qui peut se faire sur des groupes d'espèces...)

Dans un premier temps, j'aurais juste tendance à retirer les notions de filtre/requêtes et d'exports dans les modules, et réserver ces actions à la synthèse. Quitte à pouvoir filtrer par module en entrée du coup (avec le cas particulier de l'import : 1 source par import).

[Adrien-Pajot]

Oui et non... c'est ce que fait pour partie la synthèse, en reprenant les infos les plus communes/transversales à la majorité des données naturalistes.

La synthèse reprend justement tous les champs du standard non plutôt que les infos communes/transversales ?

et peuvent ne pas être pertinents dans certains protocoles / l'occurrence n'est pas la clé d'entrée la plus pertinente

C'est là que le coeur d'occurence intervient. Dans le standard justement ils parlent de sujetObservation qui est vraiment le "qui a vu quoi où et quand?" :

Or, dans chacun des protocoles cités (surtout CMR, monitoring ou groupes d'espèces), on retrouvera tous ces champs. Pour la capture, un taxon à un endroit donné, le marquage permet juste d'aller à l'individu et la recapture pareil, de nouveau occurence de taxon. Pour les groupes d'espèces et les monitoring, toutes les informations sont retrouvées de manière encore plus directe. D'autant plus que l'entrée métier ne se fait pas forcément par l'occurence mais que cela peut juste se matérialiser en BDD. Ce qui se passe ne changerait pas grand chose à l'expérience utilisateur actuelle finalement.

Je pense que le débat est surtout dans la gestion nationale. Avec @camillemonchicourt on discutait de savoir si un standard de protocole était un standard d'occurence élargie comme le SINP a l'air de le proposer (tu me dis si je confonds Camille !) mais si c'est le cas, cela aura du sens d'implémenter ça dans les outils.

On a l'air de toucher à un sujet global de toutes façons qui me dépasse en terme de gestion mais au niveau des petits changements GeoNature avant d'envisager de plus gros développements :

• Faire en sorte que la synthèse soit la seule porte d'entrée de visualisation, filtre, requête, exports basiques.
• Ne pas doubler l'information entre OccTax et la synthèse
• Permettre d'accéder facilement à l'édition de la source des données depuis validation (comme c'est déjà le cas pour beaucoup)
• S'intéresser à la problématique de l'import
• Voir pour les données d'habitats

Après pour les gros changements... on verra ce que disent les SINP et les besoins métiers de plus en plus présents en termes de protocoles !

[camillemonchicourt]

On a eu cette réflexion de centraliser les occurrences entre tous les modules et toutes les données, au moment de la refonte de GeoNature en v2 en 2017 : https://github.com/PnX-SI/GeoNature/issues/171

[camillemonchicourt]

De mon côté, je reste assez sceptique sur le fait de faire de l'occurrence de taxons le cœur de toute donnée de biodiversité, notamment quand il s'agit de protocoles de suivi.

Le principe de GeoNature est de pouvoir ressortir et remettre à plat sous forme d'occurrence de taxon toutes données provenant de tout protocole. Mais l'inverse est plus discutable.

Par ailleurs, je ne pense pas qu'il faille faire de la synthèse la principale porte d'entrée de recherche et exports mais qu'il est important d'en avoir une dans chaque module justement car c'est là que l'on trouve une donnée d'un protocole avec sa richesse et son contexte.

• Retrouver et exporter toutes les visites d'un site.
• Retrouver tous les sites où l'on a vu telle espèce.
• Retrouver toutes les positions d'un individu dans CMR
• Exporter des visites d'un suivi d'espèce avec tous ses champs spécifiques au suivi
• Etc ...

C'est seulement pour Occtax que l'on peut se poser la question car la donnée y est dans une forme et une structure de donnée très similaire à ce qu'il y a dans la Synthèse. Mais là aussi c'est discutable. Dans GN1, l'équivalent d'Occtax n'était qu'un formulaire de saisie, modification. Pour revenir sur une saisie il fallait passer par la synthèse et les retours des utilisateurs n'étaient pas très bons et cela apportait de la confusion.