Module observation citoyenne #242
Comments
|
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). |
camillemonchicourt
changed the title
|
Exemple intéressant : http://urbangene.heig-vd.ch |
|
A articuler avec 65MO |
|
En effet, ça correspond tout à fait à l'idée du projet. |
|
Je viens d'avoir un échange avec l'équipe de 65MO. 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 : 1. ACCUEIL
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. 2. LISTE/CARTE DES OBSERVATIONS
PHASE 2 :
3. AJOUT OBSERVATION
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 :
4. ARCHITECTURE et BASE DE DONNEES
|
|
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). 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. 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. 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. Il y aura un schéma gn_citizen dans la BDD GeoNature. |
|
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 ... |
|
Merci à vous pour ces échanges très intéressants.
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. 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. 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 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. 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. 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. 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. 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. 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. |
Mince. Voilà qui va être fâcheux pour nos projets de saisie citoyenne dans un village sans web et autres sites isolés. |
|
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. 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é. 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
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. 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 |
|
Merci Olivier pour ces remarques intéressantes. |
|
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 ? ) 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 :
The text was updated successfully, but these errors were encountered: