Flore Prioritaire - Définition générale du projet

[richardvergely]

Refonte du module GeoNature v1 du protocole Flore Prioritaire du réseau Flore Sentinelle.

Création d'un modèle de données du protocole sur Géonature v2.

Première version du MCD :

Et la traduction en MLD :

Les tables créées dans ce module sont déclinées de la sorte :

• t_zprospect décrit les zones de prospection de la flore prioritaire.
• t_apresence décrit les aires de présence de la flore prioritaire au sein des zones de prospection.
• cor_zp_area détermine l'appartenance des zones de prospection à des territoires donnés.
• cor_ap_area détermine l'appartenance des aires de présence à des territoires donnés.
• cor_ap_perturb décrit les différentes perturbations constatées au sein des aires de présence.
• cor_zp_obs décrit les observateurs des zones de prospection.

[gildeluermoz]

Justement, il n'y a pas de lien avec gn_monitoring car ce n'est pas un protocole de suivi. Il n'y a ni site stable, ni visite.

[camillemonchicourt]

Evolutions retenues le 27 mars 2019 :

Suite à notre réunion de ce matin, voici les conclusions pour le V2 du protocole Bilan Stationnel / Flore prioritaire.

1. GENERAL

Le protocole est repositionné sur un objectif de bilan sur la conservation. Il ne permet pas de faire du suivi.
Nouveau nom = Bilan conservatoire Flore

2. MODELE DE DONNEES

• Etape 1 - Surface = OK, on garde comme actuellement
• Etape 2 - Phénologie = OK, on garde comme actuellement
• Etape 2 bis - Habitat = On ne garde que l'état dominant de l'habitat (3 valeurs dans une liste). Pour la migration des données, tout ce qui aurait été saisi dans les autres champs est rapatrié dans le commentaire général de l'AP
  On bascule les perturbations dans l'étape Habitat. On garde une liste de Perturbations (à remplacer par la liste UICN) mais pour chaque perturbation on indique Effective ou Potentielle (Booléen). Pour la migration des données, on passe toutes les anciennes perturbations en Effectives
• Etape 3 - Fréquence. On ne garde qu'un champs "Fréquence estimée (%)". Pour la migration, toutes les autres infos (transects...) dans le commentaire global de l'AP
• Etape 4 - Dénombrement. On ne propose qu'un seul dénombrement, on ne distingue plus stérile et fertile. Un champs nombre min et un nombre max (pour ceux qui voudraient indiquer des classes), min = max par défaut (voir Occtax) + liste "Objet dénombrement" (voir OCctax). Pour la migration des données, on additionne les stériles et fertiles dans les champs Nombre min et nombre max. On garde les éventuelles autres informations dans le champs Commentaire général de l'AP
• Perturbations. Basculées dans l'étape Habitat
• Physionomie. Cette info est relative au taxon et non pas à l'AP. On supprime ce champs, mais lors de la migration, on rapatrie cette info dans TaxHub dans un attribut dédié à créer.

[gildeluermoz]

Le protocole de recueil change : plus de transect, plus de distinction stériles/fertiles.
Les typologies changent : perturbations, habitat
L'organisation des données change : dénombrement, physionomie, perturbations (j'ai pas bien compris le lien avec habitat mais c'est pas grave)
Le MCD de la base du réseau a déjà évolué, il est différent du MCD de la base PNE (ajout habitat, menaces, état de conservation, transects fixes, ...). C'est probablement la cause du fait que les données PNE ne remontent plus dans la base réseau via la synchronisation automatique Talend.

Conséquences

• Les agents PNE saisissent sur l'application mobile mais ils ne peuvent plus ni voir ni modifier leurs saisies en web.
• L'application mobile V1 en service au PNE ne couvre pas l'ensemble des modifications intervenues dans la base du réseau, elle devient incompatible avec les évolutions prévues pour la V2.
• Les évolutions protocole et MCD entre V1 et V2 provoquent une discontinuité dans les données et les usages qui peuvent en être fait sont à questionner.

Questions

• Est-il pertinent de fusionnées les données existantes de la V1 avec les futures données de la V2 ?
• Considère t-on qu'il y a lieu de créer un nouveau jeu de données ?
• Quelle place pour le mobile ? Y aura t-il une V2 ?
• Quid du référentiel utilisateurs ?

Propositions

• Arrêter l'usage de l'application mobile au PNE (obsolète) ainsi que la synchronisation entre la base réseau et la base PNE.
• Saisir en web, sur l'application du réseau en V1 puis en V2
• en l'absence de référentiel observateurs, la question du partage des id_role des observateurs entre les 2 bases reste non résolue. Dans l'attente la solution est de remonter les observateurs en text.
• Remonter les données PNE du réseau dans la base PNE en FDW (sans id_role)
• Les données saisies jusque là en web et mobiles sont archivées dans le schéma florepatri
• Remonter les données vers la synthese en trigger sur le fdw ou via une tache cron (investiguer)

[camillemonchicourt]

Oui je partage ces propositions.
Mais à priori on a plutôt prévu de migrer les anciennes données vers le nouveau modèle.
Les évolutions visent à simplifier et recentrer le protocole sur ses objectifs car là c'était parti un peu dans tous les sens.