pnx-si / gn_module_suivi_flore_territoire Goto Github PK

Voir PnX-SI/Nomenclature-api-module#9.

• Insérer le cd_nomenclature et laisser les id_nomenclature se générer automatiquement avec le serial.
• Préfixer le type de nomenclature TYPE_PERTURBATION en SFT_TYPE_PERTURBATION.
• Renseigner le champs source quand on insère le type de nomenclatures et les nomenclatures spécifiques du module, en mettant SFT dans source.

Si on filtre les ZP par organisme, les ZP qui ont été visitées par plusieurs organismes n'affichent alors plus que l'organisme filtré.

Dans la liste des visites, seul 1 observateur sur les potentielles différents utilisateurs est affiché.
Afficher tous les observateurs ou sinon un nombre d'observateurs avec leur détail au détail du nombre.

• Exporter une visite maille et attributs (absence/presence, date, obs...) avec une ligne par maille
• Exporter toutes les visites d'une ZP (une ligne par maille, mailles dupliquées par autant de visites)
• Exporter toutes les visites des ZP listées

Une absence ou présence d'un taxon = une occurrence de taxons.

A la racine du projet et dans le répertoire backend/

Afficher l'organisme d'un site sur la base des organismes de ses différentes visites ?
Idem sur le détail d'une visite, nous avons la liste des observateurs, mais afficher aussi leurs organismes (entre parenthèses ?)

Quand on va sur une ZP puis sur une visite, on ne sait plus forcément où on en est et comment retourner à la ZP ou la liste des ZP.

Un fil d'ariane permettrait d'améliorer cela.
Suivi Flore Territoire / ZP 12 / Visite 8 du 24-07-2018

• Un fichier SQL pour la création des tables, fonctions, contraintes et triggers
• Un fichier pour les données minimales (nomenclatures)
• Un fichier pour les données exemple

Ne prendre que ceux correspondant au module souhaité (en paramètre) et qui sont actifs.

IdMenu dans https://github.com/PnX-SI/gn_module_suivi_flore_territoire/blob/master/frontend/app/afficheMaille.component.html

Et autres ?

• Par taxon
• Par année de visite
• Par organisme (par l'organisme des utilisateurs ayant visités les ZP)

Pour les filtres Organismes et Communes, il y a encore des valeurs listées en dur (Test1, Test2) à supprimer.

A voir aussi si la valeur TOUS dans les listes est utile.

Enfin le filtre Organisme, affiche chaque organisme autant de fois qu'il y a d'utilisateur dans celui-ci.

Dans les scripts SQL, on remplit la table gn_monitoring.cor_site_application, utile au fonctionnement de l'application : https://github.com/PnX-SI/gn_module_suivi_flore_territoire/blob/master/data/SFT_data.sql#L61-L65

Pour cela on utilise la variable MY_ID_MODULE. Cependant quand on installe le module, on ne connait pas encore son id_module donc il faudrait faire sans cela et supprimer ce paramètre du setting.ini.

On a essayé de la modifier en :

-- Insérer dans cor_site_application les sites suivis de ce module
INSERT INTO gn_monitoring.cor_site_application 
with idapp AS(
SELECT id_application FROM utilisateurs.t_applications
WHERE nom_application = 'suivi_flore_territoire';
)
SELECT bs.id_base_site, idapp
FROM gn_monitoring.t_base_sites bs
JOIN pr_monitoring_flora_territory.zp_tmp zp ON bs.base_site_code  = zp.id::character varying;

Mais cela n'a pas fonctionné.
De plus il ne faudrait pas utiliser pr_monitoring_flora_territory.zp_tmp dans cette requête.

A creuser.

Lors de l'installation, la partie qui remplit la table gn_monitoring.cor_site_application n'est pas opérationnelle : https://github.com/PnX-SI/gn_module_suivi_flore_territoire/blob/master/data/SFT_data.sql#L67-L74

Elle fonctionne bien si on la lance en SQL après l'installation.

Certainement car la création de l'application intervient après l'éxecution du install_db.sh ?

Le module s'appuie sur une liste de taxons définies au niveau de TaxHub.

J'ai créé une liste de base : a3a01c7

On a déjà une liste SAISIE OCCTAX (id = 100) donc j'ai mis ID = 30 au pif pour celle-là, mais ça n'a pas vraiment de sens.

Je me pose la question de basculer le champs id_liste de taxonomie.bib_listes en serial et de ne pas commencer avec ces id_listes 100 et 30 (et ensuite ???) qui ont peu de sens.

Les exports renvoient une erreur sur les fiches visite.
Requête trop longue à répondre ?

Idem sur Liste ZP et Détail ZP

install_db.sh sans le dataset exemple.

Actuellement les scrolls sont appliqués sur toute la page. Du coup quand on descend dans la liste, le formulaire ou autre, cela masque en partie la carte.

Il serait plus fonctionnel que seulement le bloc de droite scrolle mais que la carte reste fixe.

L'installation du module a été pas mal testée et ajustée aujourd'hui, dernier jour de @Khanh-Chau

Cependant le module ne renvoie aucun site.

Potentiellement car il n'y a pas de communes sur nos GeoNature à l'endroit où on été insérées les ZP d'exemple.

En effet la route /sites filtre sur communes : https://github.com/PnX-SI/gn_module_suivi_flore_territoire/blob/master/backend/blueprint.py#L31-L61

Si on refait la requête en SQL, celle-ci ne retourne aucune ligne :

SELECT ti.id_infos_site, ti.cd_nom,
            max(tv.visit_date_min),
            tx.nom_complet,
            count(tv.id_base_visit),
            bo.nom_organisme,
            la.area_name
FROM pr_monitoring_flora_territory.t_infos_site ti
LEFT JOIN gn_monitoring.t_base_visits tv ON tv.id_base_site = ti.id_base_site
LEFT JOIN taxonomie.taxref tx ON ti.cd_nom = tx.cd_nom
LEFT JOIN gn_monitoring.cor_visit_observer cvo ON cvo.id_base_visit = tv.id_base_visit
LEFT JOIN utilisateurs.t_roles tr ON tr.id_role = cvo.id_role
LEFT JOIN utilisateurs.bib_organismes bo ON bo.id_organisme = tr.id_organisme
LEFT JOIN gn_monitoring.cor_site_area csa ON csa.id_base_site = ti.id_base_site
LEFT JOIN ref_geo.l_areas la ON la.id_area = csa.id_area
WHERE la.id_type = 25
GROUP BY ti.id_infos_site, ti.cd_nom, tx.nom_complet, bo.nom_organisme, la.area_name

La requête est à ajuster pour retourner les sites, même si ils n'ont pas de commune dans gn_monitoring.cor_site_area

Vérifier que l'utilisateur ne tente pas de créer une visite sur un site qui a déjà une visite dans la même année. Si il le fait, l'inviter à compléter la visite existante.

Faire les triggers alimentant la Synthèse depuis la Synthèse.
Chaque observation de présence dans une maille = 1 occurrence de taxon à envoyer dans la Synthèse.

On pourrait aussi envoyer les observations de mailles d'absence vers les exports SINP qui prévoient les occurrences d'absence mais pas souhaité de mettre ça dans la Synthèse.

Dans frontend/app/

S'appuyer sur le CRUVED (de GeoNature et/ou du module) avec les actions par portée

Le code listant des visites dans une datatable est dupliqué entre le module "detail-visit" et "list-visit".
Il serait intéressant de créer un composant pour éviter cette duplication.

La commune est affichée autant de fois qu'il y a d'observateurs dans les différentes visites

Sur la fiche d'un site, le nom de la même commune s'affiche autant de fois que le site contient de visites.
Il ne devrait pas y avoir de doublon de noms de commune.

Si une visite n'a pas d'observateur défini, alors elle n'apparait pas dans la liste des visites d'une ZP, mais dans le compteur du nombre de visites.

Ce cas ne devrait pas exister car le formulaire impose au moins un observateur par Visite, mais ce cas devrait être géré quand même.

Pouvoir exporter les mailles d'une ZP dans un format utilisables par les appareils mobiles, dans Oruxmaps par exemple.

En GeoJSON ou SHP à minima car c'est disponible dans GeoNature comme format. Éventuellement GPX, KML ?

Liste des ZP :

• Colonne nomenclature à renommer Taxon
• Réduire la largeur des colonnes et ajouter une colonne Date dernière visite
• Hauteur carte et liste remplissant le Viewport Height
• Paginer la liste avec paramètre ou selon taille ecran
• Highlight liste moins sombre
• Zones de prospection

Fiche d'une ZP :

• Ne pas afficher Type site et Site actif
• Afficher ce qu'il y a dans base_site et info_site (Name et description et taxon)
• Commune : Vérifier le remplissage de cette info : #9
• Police des onglets à homogénéiser
• Faire un bloc blanc avec les onglets pour intégrer le contenu
• No data to display >> Aucune visite sur ce site
• Actions : Ne pas titrer et réduire les colonnes
• Ne pas afficher l'id de la visite
• Observer >> Observateur(s)
• Ajouter une colonne X pr / X abs ?
• Ajouter une nouvelle visite (au lieu de Rajouter)

Ajout visite :

• Date par défaut = aujourd'hui ?
• Hauteur carte à agrandir
• Ajouter une visite sur la ZP xxx (nom taxon)
• Type(s) de perturbations
• Ajouter validateur sur champs obligatoires (date et observateurs)
• Police bouton Instructions et supprimer la première ligne d'info. Clic droit
• Déplacer commentaire après perturbations
• Statut des mailles >> Faire un bloc plus léger (composant alert ?) et mettre les lignes sur une seule ligne
• Enlever tooltip mailles cartes
• Visualiser les visites précédentes >> Basculer en rouge et renommer en Annuler

Fiche visite :

• Informations de la visite
• Ne pas afficher identifiant de la visite
• Mailles de présence : / Mailles d'absence :
• Listes : Pas de virgule à la fin
• Ajouter bouton Modifier
• Intégrer la liste des autres visites pour y accéder directement

Edition visite :

• Simplifier en affichant directement les champs éditables
• Ajouter le commentaire
• Supprimer l'id visite
• Factoriser add et edit ?

Dans la conf du module, on peut modifier le centre par défaut.
Par contre on ne peut pas modifier le niveau de zoom par défaut ?
Quelle est la valeur utilisée ?

Quand je clique sur une ZP sur la carte qui est dans une autre page, se déplacer dessus pour la trouver facilement dans la liste.

Actuellement cela ne filtre que dans le tableau donc sur la dernière visite.
La recherche doit renvoyer toutes les ZP qui ont eu une visite lors de l'année recherchée.

Lorsqu'on veut modifier une visite, les observateurs et perturbations préalablement saisis ne s'affichent pas.

Si les champs Nom et Description du site sont vides.

L'alerte semble fonctionner quand on tente de saisir une visite sur une ZP qui a déjà été visitée cette année.
Par contre, après cela, même si on modifie l'année de la visite en cours de saisie, l'enregistrement ne fonctionne pas.

Actuellement on scrolle dans toute la page.

Modifier

        ).join(
            Taxonomie, TInfoSite.cd_nom == Taxonomie.cd_nom).outerjoin(
            corVisitObserver, corVisitObserver.c.id_base_visit == TVisiteSFT.id_base_visit

en :

        ).outerjoin(
            Taxonomie, TInfoSite.cd_nom == Taxonomie.cd_nom).outerjoin(
            corVisitObserver, corVisitObserver.c.id_base_visit == TBaseVisits.id_base_visit

?

Ici : https://github.com/PnX-SI/gn_module_suivi_flore_territoire/blob/master/backend/blueprint.py#L51-L53

Dans le cadre de ce protocole, la plupart des relevés sur le terrain se font à l'aide de pointage GPS.

Le plugin Leaflet.FileLayer, développé dans la cadre du projet Geotrek, permet d'ajouter un bouton pour charger un GPX (ou GeoJSON ou KML) sur la carte pour le faire afficher :

Le contenu du GPX est alors affiché sur la carte et le contenu de sa balise name est affiché au survol d'un objet linéaire :

ou ponctuel :

A voir comment intégrer ce plugin LeafLet au projet et ensuite idéalement l'intégrer de manière générique au module Map global de GeoNature (PnX-SI/GeoNature#256).

Ce plugin permettra ainsi de faciliter la saisie en visualisant directement dans l'interface les relevés terrain réalisés.

A vérifier.
Calculé automatiquement par trigger remplissant cor_site_area ?

Par défaut la liste des observateurs, se base la liste "Observateurs Occtax" (utilisateurs.t_menus.id_menu = 1) créée lors de l'installation d'Occtax.

L'id_menu utilisé est paramétrable (https://github.com/PnX-SI/gn_module_suivi_flore_territoire/blob/master/config/conf_gn_module.toml.example#L14)
Il lui faudrait donc plutôt une liste dédiée ("Observateur SFT").

A voir si on la créé lors de la création de la BDD de SFT et comment on la peuple par défaut (avec les groupes "Grp_admin" et "Grp_en_poste" par exemple, si ils existent encore dans la table utilisateurs.t_toles)

Utiliser le composant SearchTaxon en le basant sur une liste de taxons liée au protocole SFT.

Le controle d'année pense qu'on essaie de créer une visite sur une année où il y en a déjà une. Et il bloque l'enregistrement.

A partir de Zones de Prospection (ZP) prospectées dans le protocole d'inventaire répété Bilan Stationnel (ex-Flore prioritaire), des ZP sont selectionnées pour faire office d'un suivi. Sur chacune de ces ZP, une espèce est prspectée par mailles de 100*100m et l'absence ou la présence de l'espèce est renseignée pour chaque maille.

La BDD s'appuie sur le module générique gn_monitoring permettant de gérer de manière centralisée les visites et les sites, de les étendre dans le schéma du protocole et d'y associer des observations.

Première version du MCD :

Lorsque nous tentons d'ajouter une visite après avoir rempli le formulaire un message "Une erreur est survenue" apparait. Elle est du à ceci:

(psycopg2.errors.NotNullViolation) ERREUR:  une valeur NULL viole la contrainte NOT NULL de la colonne « id_dataset »
DETAIL:  La ligne en échec contient (9, 115, null, null, null, 2020-03-01, 2020-03-01, null, null, Test, c28ff9f7-227b-41a1-a6c4-bdbcd3417aa9, 2020-03-24 19:04:35.744845, null)

[SQL: INSERT INTO gn_monitoring.t_base_visits (id_base_site, id_digitiser, id_dataset, id_module, visit_date_min, visit_date_max, id_nomenclature_obs_technique, id_nomenclature_grp_typ, comments, uuid_base_visit, meta_create_date, meta_update_date) VALUES (%(id_base_site)s, %(id_digitiser)s, %(id_dataset)s, %(id_module)s, %(visit_date_min)s, %(visit_date_max)s, %(id_nomenclature_obs_technique)s, %(id_nomenclature_grp_typ)s, %(comments)s, (SELECT uuid_generate_v4() AS uuid_generate_v4_1), %(meta_create_date)s, %(meta_update_date)s) RETURNING gn_monitoring.t_base_visits.id_base_visit]
[parameters: {'id_base_site': '115', 'id_digitiser': None, 'id_dataset': None, 'id_module': None, 'visit_date_min': '2020-03-01', 'visit_date_max': '2020-03-01', 'id_nomenclature_obs_technique': None, 'id_nomenclature_grp_typ': None, 'comments': 'Test', 'meta_create_date': None, 'meta_update_date': None}]
(Background on this error at: http://sqlalche.me/e/gkpj)

Est ce que l'obligation d'avoir un id_dataset est due à une évolution de GeoNature ?

En utilisant le composant créé pour la Synthèse.
En pouvant paramétrer les types de zonages qui sont proposés en filtre.
En ne listant que les zonages qui ont au moins une donnée ?

Quand on créé plusieurs visites sur un même site d'affilée sans rafraîchir le navigateur, le compteur dynamique de mailles présentes ou absentes part des valeurs des visites précédentes :

• Vérifier et documenter la méthode d'intégration de ZP dans la BDD
• Mettre en place et documenter une procédure d'intégration de données historiques (visites de mailles sur des ZP)

Côté backend de gn_monitoring, il y a actuellement une route qui renvoie la géométrie des zonages intersectant un site : https://github.com/PnX-SI/GeoNature/blob/develop/backend/geonature/core/gn_monitoring/routes.py#L83

Dans notre cas, ce n'est pas la géométrie des zonages dont on a besoin mais uniquement leur nom.
Pour le moment, une route a été ajoutée dans le module pour cela (https://github.com/PnX-SI/gn_module_suivi_flore_territoire/blob/master/backend/blueprint.py#L334-L357), mais à regrouper et migrer dans gn_monitoring à terme car c'est une fonction générique, pas liée à ce module.