Module sites intégré dans le coeur de la plateforme ?

[lpofredc]

Dans le cadre d'un projet de recensement participatif des mares de l'agglomération de Grenoble, la LPO Isère et la Métropole de Grenoble ont lancé le développement d'un module "mares" dont la généricité pourra également s'appliquer à d'autres types de sites (arbres remarquables, bâtis, etc.). C'est ascan.io et @jolleon qui ont en charge ce projet.

Au regard de la complémentarité de cette approche "sites" avec celle d'observations opportunistes, je propose ce module, initialement prévue en module externe (gnc_site), intègre directement le cœur de l'application GeoNature-citizen. Le choix d'une approche "observation" ou une approche "site" sera alors défini au niveau du programme.

L'objectif de cette plateforme "site"

Il est de répertorier des sites (dans un premier temps des mares):

• Pour chaque site, de pouvoir saisir des relevés à différentes dates (= visites, pour caractériser par exemple l'état de la mare) ;
• Pour chaque site, de pouvoir saisir des observations d'espèces à différentes dates (dans la table des observations du module principal GeoNature-citizen).

Pour les visites

Pour plus de généricité et réduire les temps de développements pour cette première version, il a été choisi que le formulaire soit automatiquement généré à partir d'une structure JSON stockée en bdd dans une table "types de sites". Ainsi, chaque type de site pourra disposer d'un formulaire adapté.
Cette fonction devrait s'appuyer sur Angular6-json-schema-form ou sur ngx-formly.

De même, les données relevées lors des visites seront dans un premier temps stockées au format JSONB en bdd. Elles pourront être présentées sous la forme d'une table structurée par vues.

Pour les observations

La saisie des observations s'appuiera sur le formulaire en cours de développement dans le coeur de GeoNature-citizen. le lien entre les observations et les sites se fera par une table intermédiaire de correspondances.

Merci pour vos retours rapides.

[jolleon]

Stocker la structure elle même dans la BDD va compliquer les choses. Je pense qu'il vaut mieux partir sur un ou des fichiers JSON (avec la structure en json schema) qui vivent à coté du code:

• la structure va être assez complexe (près d'une vingtaine de champs avec des types divers) donc il vaut mieux pouvoir travailler dessus et l'auditer comme du code
• en fonction des modules frontend choisis certains risquent d'avoir besoin de cette structure dans un fichier
• l'avoir dans un fichier permettra aussi de l'integrer facilement avec des libs coté serveur, par exemple pour validation des inputs ou auto-générer les docs swagger

[jolleon]

Pour ce qui en est de construire le module mares directement dans GNC vs dans un module externe "sites", le mettre directement dans GNC me parait être un peu plus simple, mais je n'ai pas tout le contexte sur l'ensemble du projet :)

[camillemonchicourt]

Oui ça semble plus pertinent de mettre ça dans le cœur car on aura 2 types de programmes :

• Ceux consistant à relever des observations d'espèces (BDD définie)

• Ceux consistant à inventorier des sites avec des informations diverses (observations d'espèces sur site et autres)

• Il est important de garder une approche simple mais aussi générique.

• Le fait de définir la structure des données des programmes SITES de manière souple et générique est intéressante, mais il faut qu'elle reste simple à mettre en œuvre pour les structures qui déploieront GeoNature-citizen

Enfin, il est important que la partie PROGRAMME ESPÈCES en cours de développement ne soit pas complexifiée ni perturbée.

De ce que je comprends :

• Il faut ajouter un champs type dans la table t_programs pour définir si il s'agit d'un programme SITES ou ESPECES. Et dans le cas d'un programme SITES, il faut aussi pouvoir définir le modèle de données JSON. Où ça ?
• La page d'un programme va être différente si on est dans un programme SITES ou ESPECES (principalement la partie qui affiche les données)
• Le formulaire de saisie d'observations va être commun et prédéfini pour les programmes ESPECES, tandis qu'il sera généré à la volée par le schéma JSON pour les programmes SITES

Très bien pour la partie PROGRAMMES SITES, mais à voir comment ne pas alourdir la partie PROGRAMME ESPÈCES en cours de développement.

[lpofredc]

Bonjour,

Oui, évidemment cela ne doit pas interférer avec les devs de la partie "PROGRAMME ESPECES".

Ce que nous avions convenu avec @patkap, c'est que le choix du type de programme dans le front sera défini au niveau de la liste des programmes. Si le programme est ESPECE ou SITE, alors la route du programme sera différente (ex: urldusite/program/obstax/{id} ou urldusite/program/site/{id}).

Pour le modèle de formulaires, @jolleon propose de les mettre dans des fichiers à part entière, pourquoi pas, dans la limite ou il en sera fait mention dans la bdd (champ json_schema_file ? dans la table des types de sites ?) afin de faire le lien entre les types de sites et les fichiers de formulaires à charger. On peut imaginer un dossier custom_form avec des modèles de types (un par type de site), adaptable par l'administrateur.

Pour les observations d'espèces sur un site, les composants et services d'observations d'espèces devraient pouvoir être réutilisés.

Pour le dev de ce volet SITE, je propose de merger les devs à cette fonction dans une nouvelle branche dev_sites

[camillemonchicourt]

OK

[samuelpriou]

Bonjour,

Dans la mesure où les développements de la partie "PROGRAMME SITES" n'interfèrent pas les devs de la partie "PROGRAMME ESPECES", c'est ok pour le PNM.

J'aime bien l'idée de @jolleon qui propose de faire le lien entre les types de sites et les fichiers de formulaires à charger. On peut effectivement imaginer un dossier custom_form avec des modèles types (un par type de site), adaptable par un admin.

Ok pour merger les devs du volet SITE dans une nouvelle branche dev_sites.

[jolleon]

Ok, donc pour résumer:

• on développe la partie Mares (i.e. première version du "programme sites") dans le dépot actuel principal GNC (https://github.com/PnX-SI/GeoNature-citizen) et on oublie https://github.com/LPOAgirPourLaBiodiversite/gnc_sites
• on développe dans notre propre fork de GNC pour pouvoir avancer sans être bloqué par les autres développements en cours (bien sur pour toute décision critique on vérifiera avec @lpofredc que c'est en accord avec la vision globale pour GNC) et on fera une pull request quand on approche de la fin du projet pour tout livrer dans la branche dev_sites du dépot principal
• on crée la structure du formulaire (et donc des données) pour le site "Mares" dans un fichier json-schema, qui plus tard pourra faire partie d'un dossier de plusieurs fichiers pour différents types de site laissant à l'administrateur le choix du type à utiliser

[lpofredc]

Oui, c'est bien ça.
Vous pouvez a minima reprendre le fichier models.py du dépot gnc_site (branche develop). Le dossier de destination des fichiers de ce module sites côté backend sera GeoNature-citizen/backend/gncitizen/core/sites côté backend et GeoNature-citizen/backend/gncitizen/core/côté frontend et
GeoNature-citizen/frontend/src/app/programs/sites côté frontend.

Le json_schema sera dans un dossier GeoNature-citizen/config/custom/form. Pour l'heure, il ne contiendra qu'un fichier mares.json correspondant au projet de mares qui nous concerne.

Le choix du fichier du fichier json-schema à utiliser doit se faire après consultation de l'API pour savoir quel trame de formulaire utiliser.

[camillemonchicourt]

Les développements de la partie SITES ont été réalisés sur le fork https://github.com/jolleon/GeoNature-citizen/tree/mares
Ils sont en production sur https://www.a-vos-mares.org

Reste donc à les rendre plus générique et les intégrer dans ce dépôt.

[samuelpriou]

Bravo @lpofredc pour ce travail !

[lpofredc]

Merci, tout le mérite revient à @jolleon et @QuentinJouet qui ont réalisé les développements de ce projet.

Au jour d'aujourd'hui, c'est un module "mares" avec le formulaire d'état des lieux détaillé inscrit "en dur" dans le code. Il devra évoluer vers un outil adaptatif permettant sur un programme d'inventorier différents types de sites avec des formulaires adaptés à chaque types de sites.

Il reste également un important d'intégration de ces développements à GeoNature-citizen qui a évolué en parallèle à ce développement (dont une montée en version d'Angular v6 > v8).

[sig-pnrnm]

Question naive (alors soyez indulgents 😉 ) :

Ce module "sites" (ou "mares", ou "arbres remarquables") pourrait répondre aux besoins de plusieurs collègues.

Nous n'avons pas d'instance GeoNature-Citizen, mais une instance GeoNature (v1 et prochainement v2).
Est-il possible (ou aurait-il été possible) d'intégrer ce module sites à GeoNature plutôt qu'à GeoNature-Citizen ?
Je vous propose plusieurs réponses :

• oui, c'est tout à fait possible : ça pourrait être un module de GeoNature
• oui, mais c'est trop tard
• non, car ce n'est pas dans l'esprit de GeoNature : GeoNature vise des scientifiques et GeoNature-Citizen vise le grand-public
• non car ce ne sont pas du tout les mêmes technologies
• ...

[camillemonchicourt]

Le mode "Site" est totalement intégré dans GeoNature-citizen, qui est un outil à part et non pas un module de GeoNature. C'est même pas vraiment un module de GeoNature-citizen mais plutôt un mode de GeoNature-citizen.

Et GeoNature-citizen est autonome et indépendant de GeoNature, même si il peut être intégré dans son écosystème, de la même manière que GeoNature-atlas. Voir #100

Ce n'est pas du tout conçu ni développé comme un module GeoNature et c'est fait pour être accessible en ligne à tous, orienté grand public, avec authentification optionnelle si on veut saisir des données etc...

[camillemonchicourt]

Fichier de description des champs du programme "mares" : https://github.com/PnX-SI/GeoNature-citizen/blob/dev/config/custom/form/mares.json

[nobohan]

Bonjour,

Nous allons utiliser Geonature-citizen dans un projet de relevés d'éléments de biodiversité dans une commune en Belgique. Je cherche à comprendre comment configurer un programme de type site. Le fichier mentionné ci-dessus (https://github.com/PnX-SI/GeoNature-citizen/blob/dev/config/custom/form/mares.json) serait bien utile mais le lien est mort.

Pouvez-vous maj le lien?

merci d'avance

[camillemonchicourt]

@lpofredc et @samuelpriou, vous avez des exemples de configuration de programmes en mode "espèces" (avec champs additionnels) ou en mode "sites" à partager ?
Merci.

[samuelpriou]

Bonjour,
Voici deux fichiers .json qui nous ont permis de configurer deux programmes en mode "espèces".

Le programme Gypaète Barbu
https://obs.mercantour-parcnational.fr/programs/13/observations :
gypaète.zip

Le programme Bouquetins des Alpes
https://obs.mercantour-parcnational.fr/programs/14/observations :
bouquetins.zip

J'ajoute également un programme "site" réalisé par @lpofredc permettant de décrire des mares.

Le programme Mares
https://www.a-vos-mares.org/participez/ :
mares.zip

Bonne journée

[camillemonchicourt]

Merci @samuelpriou, une documentation générale sur la configuration des champs additionnels des programmes était prévue, non ?

[samuelpriou]

Oui...
Je vais le faire cette semaine.

[lpofredc]

Je viens de crééer un GIST avec quelques configs de la LPO AuRA:
https://gist.github.com/lpofredc/a85e994776efd6a63757d2817fd7862c

Vous pouvez utiliser ce site pour tester et développer vos propres configs.

En parallèle, je réfléchis à un moyen de partager toutes ces ressources (hub Citizen, voire GeoNature ?).

[lpofredc]

... le site de test...
https://partage.lpo-aura.org/minisite/ajsf/