Closed camillemonchicourt closed 6 years ago
J'intégrerai aussi une page avec la carte/liste de TOUTES les observations faites dans la cadre du programme. Dès qu'une saisie est faite, elle apparait dans ce module. Ca permet d'être dynamique, réactif et que les utilisateurs aient un retour direct sur leur participation et voit celles des autres, éventuellement s'auto-corrigent...
Le fait de valider les données du programme avant de les intégrer dans la Synthèse, les exports partenaires, l'atlas global... est un autre sujet et concerne la chaine global du GeoNature. Mais au niveau de chaque programme, je trouve ça important que les données ne soient pas verrouillées et bloquées par des attentes de validation.
J'oubliai aussi les médias (photos ou autre). On a prévu de développer un composant media dans GeoNature (pour pouvoir associer une photo, un son à une observation du Contact ou tout autre protocole). On pourra réutiliser ce composant Angular pour l'ajout de photo sur une observation d'un programme d'observation citoyenne.
Exemple intéressant : http://urbangene.heig-vd.ch Dont le code est disponible sur Github : https://github.com/MediaComem/urbangene
A articuler avec 65MO http://cesco.mnhn.fr/fr/content/recrutement
En effet, ça correspond tout à fait à l'idée du projet. La plaquette de présentation est dispo sur ce lien : http://vigienature.mnhn.fr/sites/vigienature.mnhn.fr/files/uploads/images/Plaquette65MO_BD.pdf A voir si le(s) module(s) "citoyen(s)" de GeoNature doivent être intégrées au projet 65MO, "labellisés" 65MO, ou rester indépendant (mais complémentaires).
Je viens d'avoir un échange avec l'équipe de 65MO. Le projet se positionne sur les programmes de sciences participatives avec un réseau de participants et d'animateur autour de données protocolées. Ils vont proposés différents outils créer du lien entre participants, rendre les données visibles entre participants pour créer de l'émulation, du dialogue mais aussi du contrôle qualité des données entre participants. Le projet intègre aussi des outils de restitution propres à chaque protocole.
Actuellement le projet se compose :
Le projet se concentre donc sur des programmes en réseau liées à des données protocolées et sur la construction de communauté de participants et de dialogue entre eux.
Il n'y a donc pas de redondance avec notre projet qui n'est pas couvert par 65MO. En effet dans notre cas, il s'agit plutôt de mettre en place une application de signalement (j'ai vu tel espèce à telle date et tel endroit) dans le cadre d'un projet territorial comme un ABC avec un besoin d'ergonomie le plus simple possible.
Premier maquettage de ce module GeoNature-citizen :
A l'arrivée sur l'application, on affiche une page d'accueil avec un message introductif. Dans l'exemple, elle est proposée sous forme de modale, simple. Cette modale comporte son template HTML que chacun peut modifier avec le contenu souhaité.
Elle pourrait aussi prendre la forme d'une page d'accueil complète qui intégrerait ou non la carte/liste des observations.
PHASE 2 :
Depuis la liste des observations ou la page d'accueil, on peut cliquer sur le bouton AJOUTER UNE OBSERVATION pour ouvrir le formulaire de saisie.
Celui-ci contient les différents champs :
gn_citizen
peut être intégré dans la BDD de GeoNature.gn_citizen
, on pourrait avoir une table qui liste les modules de Collecte citoyenne. id_liste
renseigné dans la conf du module)gn_meta
de GeoNature + un trigger qui alimente le schéma gn_synthese
depuis le schéma gn_citizen
A lecture de toutes les très bonnes idées déjà détaillées, voici les points que nous souhaiterions voir pris en compte.
Le système d'identification par la création d'un compte avec une adresse mail valide nous semble indispensable pour pouvoir utiliser les données recueillies dans ce cadre notamment pour les raisons suivantes :
Il serait utile de pouvoir extraire facilement les adresses mails des contributeurs à la base de données notamment si les données participent à un autre projet (je me souviens que c'était très compliqué pour l'INPN lorsqu'ils ont du mettre toutes les données de cardobs en ligne et de faire le tour de tous les utilisateurs de l'outil qui avaient contribué). Cela permettrait aussi de pouvoir animer le réseau d'observateurs, de partager des découvertes, d'inscrire les observateurs à une newsletter...
Le système de badge peut inciter certains contributeurs à se prendre au jeu en mettant des rangs/grades/statuts/badges/niveau... aux observateurs. Ainsi ont peu imaginé que le nombre d'obervations soit rappelé en dessous du nom de l'observateur, ou un certain nombre de points selon le nombre de données saisie et l'ancienneté de l'observateur; la régularité des observations (3mois d'affilée avec au moins 1 obs, 6mois, 1an...) Désignation du meilleur contributeur de l'année.......... Bref, tout est possible c'est à définir si quelqu'un d'autre pense que c'est une bonne idée.
Il faudrait alors définir une petite charte qui serait envoyée par mail et qui rappelle les conditions dans lesquelles les données peuvent être utilisées par les établissements.
OK pour associer des médias, ça nous semble également indispensable pour faciliter la validation.
OK pour la validation dans la synthèse. Cependant la finalité des données de la synthèse en interne est d'offrir une seule table comprenant toutes les données validées qui sont mobilisables pour les portés à connaissance. Il faudrait donc pouvoir s'assurer que des données non validées n'apparaissent pas dans les données utilisées par les différents chargés de missions afin de garder un jeu de données propre et fiable. Il nous semble également que le SINP souhaitent que ces données issues de collecte citoyenne soient mises dans des schémas différents et restent traçables, même une fois validées. Il faut donc s'assurer que cette traçabilité reste possible.
Concernant le stockage des données, il est bien prévu que le module de Collecte Citoyenne ait son propre schéma avec ses tables propres dans la BDD, mais aussi que ses données alimentent la Synthèse comme les autres modules/protocoles (par trigger). Pour avoir une approche unifiée et globale dans GeoNature, on a prévu de valider les données au niveau de la Synthèse, pour ne pas à avoir à développer des interfaces de validation spécifiques à chaque module. La Synthèse comprendra donc des données validées/non validées/invalidées mais cela ne prédéfinit pas comment elles seront accessibles et diffusées. On pourra par exemple choisir que seules les données validées soient affichées ou exportées, soient diffusées dans l'API public, soient diffusées dans GN-atlas etc...
Concernant l'identification. En effet si elle est imposée, elle permet d'avoir plus d'infos comme tu le mentionnes. Mais elle constitue aussi un frein important à la participation. Par ailleurs, on peut envisager de ne pas avoir d'authentification mais de proposer ou imposer un nom d'observateur. Cela sera moins carré et permettra moins de choses que de le gérer proprement dans la BDD. Cela ne permettra pas en effet d'avoir des infos sur chaque utilisateur et d'afficher des badges ou nb d'obs etc...
Du coup mon idée initiale était de commencer par un module simple sans identification, puis de l'enrichir dans un second de la possibilité de mettre en place une identification. Les 2 seraient ainsi possible au moment de la mise en place du programme de Collecte citoyenne.
C'est une piste pour proposer en premier lieu un outil plus simple à développer mais aussi plus simple à utiliser puis de l'enrichir. C'est aussi pour pouvoir commencer les développements avec un petit budget puis faire évoluer l'outil.
Mais pour évaluer le surcout, on peut directement le mettre en option dès le premier cahier des charges.
D'une manière générale quelles conséquences aura ce module très "à coté" de l'objet principal et professionnel de GeoNature sur le MCD, l'organisation des contenus de la base, les fonctionnalités de GeoNature et notamment les modules synthèse et validation.
L'intégration des observations en synthèse est à évaluer avec précaution et pose de nombreuses questions.
Autres questions :
A savoir :
Les conséquences sont uniquement au niveau de la BDD car tout le module et les interfaces ne seront pas dans GeoNature mais bien à part, à côté, comme GeoNature-atlas. Donc il n'y a pas de conséquences. Hormis sur la question des observateurs à bien réfléchir.
Il y aura un schéma gn_citizen dans la BDD GeoNature. Libre à chacun de les envoyer dans la Synthèse ou non. Si oui, elles seront traitées comme les autres sources de données. La question de la validation, des métadonnées et de l'affichage par exemple ne sera pas différent des autres sources de données.
Si le module validation est générique aussi pour ce module, tu envoies toutes les données de ce module dans la synthèse pour ensuite les valider. Donc dans la synthèse tu mélanges bien citizen et le pro ... Si tu dis que ça ne pose pas de soucis...
Merci à vous pour ces échanges très intéressants. Pour répondre aux inquiétudes de Gil, voici quelques éléments :
Donc dans la synthèse tu mélanges bien citizen et le pro ...
En effet oui. Mais n'oublies pas que le module de validation (en cours de développement) ajoute cette notion de "statut de validation" à chaque donnée de la synthèse. Du coup, les données en provenance du module citoyen auront un statut de validation particulier qui permettra de les filtrer pour les utilisations derrière GeoNature (GeoNature-Atlas par exemple).
Ne maitrisant pas tous les tenants et aboutissants de GeoNature, v2 en particulier, je ne vois donc pas en quoi cela poserait un souci ?
Selon les discussions en cours pour le développement du "module validation", il a été retenu de se baser sur la synthèse, mais de construire des filtres de recherche pour la validation. Parmi ces filtres, cela me fait penser qu'il faudra aussi pouvoir filtrer par "module/protocole source", et donc de ne faire la validation que pour (ou pour tous sauf) le "module citoyen".
Si le module citoyen est totalement indépendant, ce n'est donc pas un module comme les autres. Je n'ai pas analysé les conséquences de ça. L'atlas a sa propre base. Il est donc lui totalement indépendant et peut fonctionner sans la base GN.
Il n'y a pas que la validation qui va distinguer ces données. Il faut analyser dans le détails. La synthèse comporte de nombreux champs et lien avec le reste de la base.
Par exemple gn_synthese.defaults_nomenclatures_value
permet de définir des valeurs par défaut pour certaines nomenclatures quand elles ne sont pas fournies. A voir si c'est toujours identique entre citoyen et pro. Sinon ce sera à définir dans citoyen.
Je repose cette question :
Toutes les structures utilisant GeoNature ne souhaiterons pas forcement avoir le même usage de ces données (atlas, synthèse GeoNature, exports). Il est donc essentiel que tous les usages reposent sur des vues paramétrées selon la volonté de chacun. Mais faire reposer la synthèse (et surtout son indispensable moteur de filtrage) sur une vue pose la question épineuse des performances.
Dit autrement comment faire pour filtrer les données de la synthèse avec un formulaire commun et des volontés d'usage différentes (la synthèse renvoie ou pas les données citoyennes et lesquelles).
quelle politique pour la gestion des données sensibles parmi les données citoyennes
Les datasets et les cadres d'acquisitions sont liés à des acteurs eux même liés à un id_organisme ou un id_role desquels sont déduit le CRUVED, utilisé en synthèse pour savoir quoi afficher. Comment reconstituer ça si on a pas d'utilisateur logué ?
Où seront mis les medias de citizen ? Dans gn_medias ou pas ? Les routes du backend de gn_medias auront besoin d'une authenfication. Il faudrait donc refaire des routes dédiées citizen pour une gestion des médias de citizen sans authentification.
gn_citizen, peut-il/doit-il avoir ses propres listes de taxons. Taxhub ? Lien potentiel entre la synthèse et le schéma taxonomie géré par taxhub; Obligation pour la synthèse de ne connaitre que taxref ?
Pour moi il y a mélange des genres et si on le fait il faut bien évaluer dans quelle mesure le cadre pro va contraindre citizen car on ne fera pas l'inverse.
En effet, ce n'est pas un gn_module au sens où il s'agit d'un module intégré dans GeoNature mais plutôt d'un outil modulaire pouvant s'intégrer (ou pas) dans l'environnement GeoNature, comme l'atlas. En effet l'atlas a sa propre BDD mais elle peut aussi être intégrée à la BDD de GeoNature comme certains ont fait.
Là ça serait la même logique que l'atlas, mais cette fois-ci en amont, alors que l'atlas est en aval.
Le module GeoNature-citizen n'aurait pas besoin de GeoNature obligatoirement, mais il aurait besoin de TaxHub.
Sa BDD pourrait être intégrée à celle de GeoNature ou non.
Concernant gn_synthese.defaults_nomenclatures_value
, beaucoup d'autres données présentes dans la Synthèse n'en auront pas. Toutes les données provenant d'autres sources, comme les données des partenaires par exemple.
Pour moi les données du module GeoNature-citizen ne sont pas différentes que des données saisies depuis d'autres outils ou fournies par des partenaires.
Concernant le fait que la Synthèse repose sur une vue, je vois ce que tu veux dire. En effet cela apporterait une souplesse très intéressante mais poserait de gros problèmes de performances non souhaitables. Éventuellement elle pourrait s'appuyer sur des vues matérialisées pour apporter de la souplesse tout en gardant les performances. Mais elle nécessiterait de mettre en place des mécanismes de mise à jour des VM. A priori je resterait sur l'idée d'une table pour rester simple.
Pour moi, le fait d'avoir des données GN-citizen dans la Synthèse ne pose pas de problème, au contraire. C'est la même chose que des données internes ou partenaires qui ne seraient pas encore validées mais apparaîtraient dans la Synthèse. On peut décider de les faire apparaître ou non lors d'une recherche/export au même titre que celles des autres cadres d'acquisition. On peut décider de les intégrer ou non dans les exports et bien sur dans les usages comme ceux de GN-atlas. Donc le fait de les intégrer/diffuser/exporter se pose après la Synthèse.
Sinon libre à chacun de ne les stocker que dans le schéma gn_citizen et de ne pas les remonter du tout dans la Synthèse. Ou bien (non souhaitable mais possible) d'ajouter une interface de validation au niveau du module GN-citizen et de ne les remonter dans la Synthèse qu'une fois validées.
Pour les données sensibles, même traitement que pour toutes les autres données dans la Synthèse.
Concernant l'organisme, dans un programme de Collecte citoyenne pour moi l'organisme associé est celui qui porte et anime le programme. Les observateurs sont ceux saisis au moment de la saisie ou INCONNU si non renseigné. D'où l’intérêt de GeoNature V2 qui dissocie les observateurs et les organismes associés à une donnée par l'intermédiaire des métadonnées du jeu de données.
En effet il y a une réflexion à avoir sur les médias. GN-citizen ne devant pas être dépendant de GeoNature et de sa gestion des médias. Ce qui pousserait à ce que GN-citizen ait son propre système de gestion des médias mais ça serait dommage. Cela fait écho avec le questionnement qu'on a eu il y a eu quelques jours, sur le fait d'externaliser la gestion des médias dans un sous-module comme celui des nomenclatures pour pouvoir l'utiliser dans d'autres projets. A voir avec @amandine-sahl
Concernant les taxons, on est parti sur l'idée qu'une instance de GN-citizen pouvait ne concerner qu'un taxon, qu'une liste de taxons (définie dans TaxHub) où tous les taxons du territoire (taxonomie.bib_noms). Donc en effet il est lié à une liste dans TaxHub. Il pourrait aussi se servir des médias et attributs présents dans TaxHub. Que Taxref à priori.
Pour moi, cela ne pose pas de problème et est juste une source de données externe comme des données saisies dans un autre outil ou fournis par des partenaires.
Cette réflexion et ces questions sont importantes à se poser mais vont dans le sens de le confirmer.
A noter aussi :
Bonjour à tous,
Pour le PAG, il serait question d'ouvrir la saisie dans le cadre de l'ABC de Saül (dans un premier temps). Les groupes taxo à couvrir seront multiples mais, d'après les échanges que j'ai pu lire, ce sera géré par TaxHub. Donc je ne vois pas de soucis si on peut faire la saisie dans un même module (qu'il s'agisse d'un oiseau, d'un escargot ou d'un champignon...). Mais je m'interroge: quelle différence entre un agent connecté et un habitant/visiteur connecté lors de la saisie? A part le cadre....
Au vu du réseau web qui règne sur notre territoire, le principal réseau utilisé est le réseau téléphonique & 3G (ou plutôt 0,3G...). Donc pour nous, il serait primordial que l'appli mobile prenne en charge cette saisie citoyenne.
Je tiens à souligner qu'ajouter la possibilité de joindre un média me semble important car il sert à la validation de la donnée. En contexte tropical (qui plus est en forêt amazonienne), ça change grandement la donne...
L'idée là est de proposer une interface très simple et accessible en dehors de GeoNature. Pour des partenaires, on peut en effet, tout à fait imaginer les faire saisir directement dans GeoNature. Dans ce cas pas besoin de ce module GeoNature-citizen.
En effet dans le module GN-citizen, on pourra définir des listes de taxons saisissables grâce à TaxHub. 1 module GN-citizen = 1 liste TaxHub
Attention, il s'agit d'une application web et non pas mobile.
Oui pour l'ajout de médias, c'est prévu.
Attention, il s'agit d'une application web et non pas mobile.
Mince. Voilà qui va être fâcheux pour nos projets de saisie citoyenne dans un village sans web et autres sites isolés. Je vais aller explorer l'étendue du projet mobile pour en savoir plus. Ça m'évitera de faire des hors-sujets...
Si vous voulez financer la déclinaison GN-citizen-mobile c'est avec plaisir !
Je me doute! :-D
Spécifications du module d'authentification de GeoNature-citizen
Spécificités à l'installation:
Lors du déploiement de l'application, la structure doit pouvoir choisir le mode d'authenfication souhaité :
Création des comptes utilisateurs:
Lorsque l'utilisateur arrive sur le site GeoNature-citizen, celui ci doit avoir la possibilité de créer un compte en fonction du type d'installation choisi. Si l'utilisateur souhaite créer un compte alors une interface permet de créer ce compte.
Lors de l'enregistrement de l'utilisateur, les champs sont:
Avant la confirmation de validation du compte :
A la fin de la création du compte, un mail de validation est envoyé à l'utilisateur pour vérifier la validité de sa boite mail. L'utilisateur valide le compte en cliquant sur le mail réceptionné. Si l'utilisateur a oublié son mot de passe ou son login, un lien de réinitialisation lui est renvoyé par mail en saisissant l'adresse mail.
Tableau de bord / compte de l'utilisateur:
C'est l'interface qui permet à l'utilisateur d’accéder aux informations qui le concernent. L'utilisateur y accède soit via un lien “Mon compte” soit en cliquant sur son login depuis l'écran de collecte citoyenne.
Il permet alors la consultation(C) et/ou la modification des données suivantes (M):
Possibilité de supprimer le compte et les données qui y sont associés (RGPD) ???
Il permet aussi d'accéder à ses statistiques :
Il permet de réaliser un export des données au format .ods reprenant tous les champs renseignés par l'observateur mais pas les données renseignées à posteriori comme la validation de la donnée.
Administration de l'authentification:
2 niveaux d'administration
1) administrateur (création/modification/suppression des animateurs + droits des animateurs)
2) animateur
Gestion des badges:
Les badges sont une forme de récompense attribuée à l'utilisateur pour sa contribution. Il doit être composé de deux systèmes.
Un système automatique (paramétrable par les animateurs) qui attribue des badges aux utilisateurs en fonction de leurs statistiques:
Un système manuel (paramétrable également par les animateurs) qui permet de regrouper les utilisateurs dans plusieurs catégories, par exemple: observateur fiable, observateur non fiable, scolaire, AEM partenaire...)
Les animateurs doivent pouvoir créer de nouveaux badges automatiques en définissant les seuils de déclenchements de ces badges selon les éléments suivants:
OK, merci pour ces compléments. Un point important est à définir : GeoNature V2 est construit pour pouvoir ouvrir la saisie/consultation de certains modules à des partenaires (assos, structures partenaires, protocoles partagés...). Dans ce cas là, on utilise les fonctionnalités de GeoNature V2 et la gestion des droits associées (CRUVED par module) intégrée dans UsersHub.
Dans le cas du module GN-citizen avec authentification, il semblerait que des partenaires soient aussi ciblés. Néanmoins la gestion des utilisateurs et organismes sera décorrélée de GeoNature et UsersHub donc il n'y aura pas de rapprochement possible (ID différents notamment).
Deux remarques :
1/ gamification: les badges doivent êtres décernés de manières non linéaires. Je m’explique, c’est une forme de valorisation inattendue qui doit surprendre et valoriser surtout les premières contributions. Pour faire avancer les contributeurs dans la courbes des contributions.
Il faut aussi prévoir un système linéaire, du type points et surtout leader board qui fonctionne très bien pour les gros contributeurs
2/offline: on doit pouvoir imaginer des solutions en progressive web app pour travailler en offiline partiel sans faire une application.
Bises Olivier
Merci Olivier pour ces remarques intéressantes. Nous conserverons probablement ces idées lors de la rédaction du CCTP.
Bonjour à tous,
Je débarque un peu en retard sur les débats mais j'essaie de rattraper le train en marche.
Quid de la gestion par un organisme de plusieurs enquêtes distinctes? On aurait 2 portails? 2 onglets ou 2 pages sur un même portail?
Concernant les champs, est-ce qu'une preuve d'existence peut être prévue? Sous forme de pseudo-champ, ou se gère autrement? Je prends l'exemple du projet citique qui nécessite une collecte et une remontée des tiques à l'INRA grand est.
Je sors un peu du cadre et ma remarque aurait davantage sa place coté synthèse mais puisque c'est abordé ici : on aura dans la synthèse des données valides, invalides, non validées : possibilité de gérer un paramètre de requpetes "données validées uniquement" coché par défaut pour éviter effectivement que toutes les données afffichées soient prises pour argent comptant comme une "réparition", ou qu'un coup d'oeil rapide donne "ouais, l'espèce est présente à tel endroit" ?
Concernant l'affichage des données citoyennes dans la synthèse, idem : on peut imaginer que cette source de données soit décochée par défaut? (avec un paramètre à l'install pour laisser le choix à la structure par exemple ? Une asso risquera de cocher oui là ou un PNR ou PNx cochera le plus souvent non à priori ? ) Coté authentification, pour une question d'animation de réseau, de retours sur investissement pour les contributeurs et de RGPD aussi, l'adresse mail semble intéressante à collecter en effet. Après, si ca se rentre dans usershub comme demandé par Gil, la table utilisateur risque de devenir un joyeux bordel avec les "j'ai oublié mon compte 11 fois, j'en fais un 12eme" et donc 12 ID observateur différents par exemple. Utiliser l'adresse mail seule comme "ID" (comme login en gros) peut être une solution?
Merci au PAG de financer l'application mobile! (ha non, j'ai mal compris? ;) )
edit : Sur les nomenclatures par défaut, le mieux serait peut etre de les paramétrer directement pour le programme en question à chaque fois? Dans la mesure ou il y a peu de chants, et que le programme en lui meme peut se baser sur une méthode ou un stade de vie en particulier par exemple?
Les développements ont commencé et les discussions continuent dans le dépôt dédié au projet : https://github.com/PnX-SI/GeoNature-citizen
Une consultation vient aussi d'être lancée : http://www.mercantour-parcnational.fr/fr/documents/developpement-dune-application-web-de-collecte-citoyenne-en-lien-avec-geonature
Détails, corrections et évolutions dans le dépôt de l'application : https://github.com/PnX-SI/GeoNature-citizen
Plusieurs structures souhaitent pouvoir mettre en place des programmes d'observation (Contact) citoyenne connecté à GeoNature.
Exemple de proposition @sig-pnrnm :
Voici les premiers éléments proposés/discutés :
Voici ma première proposition :