GeoNature
GeoNature copied to clipboard
PnX-SI
Filtrer les métadonnées par zonage
Il est souhaité pouvoir filtrer les CA ou les JDD par zonage, notamment par région ou département. On ne dispose pas directement de l'info du zonage concerné par un CA ou un JDD, mais on peut le déduire des zonages des données qu'il contient.
C'est un peu lourd comme requête, mais sur un test rapide sur la BDD du PNE, on peut retrouver les JDD en filtrant sur un département en 2 secondes, ce qui est tout à fait convenable :
select distinct td.id_dataset, td.dataset_name from gn_meta.t_datasets td
join gn_synthese.synthese s on s.id_dataset = td.id_dataset
join gn_synthese.cor_area_synthese cas on cas.id_synthese = s.id_synthese
where cas.id_area = 1593768 -- Isère
--where cas.id_area = 1593734 -- Hautes-Alpes
group by td.id_dataset
Il y a d'ailleurs peut-être mieux comme requête ?
Sur cette base, on pourrait donc ajouter les filtrages des métadonnées par zonage. Comme pour les filtres géographiques dans la synthèse (https://github.com/PnX-SI/GeoNature/blob/master/config/default_config.toml.example#L234), il serait bien que les types de zonages proposés comme filtres soient paramétrables.
Je trouverai ça très intéressant, et je crois qu'on en a déjà parlé, d'associer une géométrie à un jeu de données et/ou un cadre d'acquisition (donc d'ajouter l'information de zonage). Cette géométrie pourrait soit être celle du ref_geo soit celle des sites monitorés. C'est une demande vraiment constante chez tous les clients que nous avons et notamment les BE mais pas que.
Pour le moment seules les bbox sont definies/prévues au niveau des metadonnees. Ca peut déjà être une première méthode d'aller intersecter ces bbox
Des travaux ont démarrés récemment autour de cette issue pour MNHN.
Ce commentaire a été écrit conformément aux échanges avec MNHN et l'équipe technique du Parc des Ecrins (@TheoLechemia , @camillemonchicourt , @bouttier).
Voici le spectre fonctionnel retenu pour ces travaux.
Description fonctionnelle
Il est demandé de pouvoir filtrer les métadonnées selon une zone géographique qui doit être déjà accessible dans la table ref_geo.l_areas.
Cette fonctionnalité sera accessible si et seulement si l'administrateur a activé ces filtres dans la configuration de GeoNature via l'ajout du booléen dans la configuration suivante :
- config_schema.py
DISPLAY_METADATA_REF_GEO_FILTER = fields.String(fields.str(), load_default=False)
- default_config.toml.example
DISPLAY_METADATA_REF_GEO_FILTER = true
Si ce champ est renseignée true, alors deux filtres seront accessibles :
- Choix du référentiel => Choix de la valeur
id_type - Saisie de la valeur de la zone => Recherche et sélection de l'entité
areaselon le champarea_name
A noter que le champ de saisie ne sera visible que si le choix du référentiel a été réalisé en première étape.
Le retour de l'autocomplétion correspondra alors à la requête suivante GET /geo/areas :
/geo/areas?area_name=saint&id_type=25
https://github.com/PnX-SI/GeoNature/blob/7fa9f345b300567a5714ec2a9ea0dbfc5bfcf7c9/backend/geonature/core/ref_geo/routes.py#L212-L216
Capture
Voici une capture des travaux en cours (les labels seront changés) :
Pour les paramètres, voir ce qui est indiqué plus haut.
Il ne s'agit pas d'ajouter 2 paramètres booléens, mais bien de faire comme pour les filtres géographiques de la Synthèse, en ajoutant un paramètre unique listant des AREA_CODE. Nomme par exemple METADATA_AREA_FILTERS
Voir le paramètre AREA_FILTERS de la Synthèse : https://github.com/PnX-SI/GeoNature/blob/master/config/default_config.toml.example#L255-L257
Si ce paramètre est vide, alors on n'affiche pas du tout de filtre géographique. Par défaut, je mettrai bien les communes, et les départements, pourquoi pas les régions.
Je suis pas super convaincu de l'ergonomie et simplicité de devoir combiner 2 champs. Commencer par choisir son type de zonage sur lequel on veut filtrer, puis choisir le zonage en question. Je préfère une liste de zonages par types de zonages activé.
Mais pourquoi pas. Si on reste sur 2 champs à combiner, il faut clarifier visuellement qu'ils vont ensemble. Et revoir le vocabulaire. Là je ne vois pas trop ce que l'utilisateur va comprendre en arrivant devant un champs "Référentiel de la zone", surtout en l'affichant comme les autres champs de recherche. "Zone géographique à utiliser" n'est pas clair non plus.
L'utilisateur par nom, par acteur, etc... Il doit comprendre de la même manière quand il filtre par "Commune", "Département", "Région" ou autre.
Je suis pas super convaincu de l'ergonomie et simplicité de devoir combiner 2 champ
Ok, faut juste bien définir précisément le comportement et l'affichage que vous préférez pour pouvoir avancer dans les devs.
de faire comme pour les filtres géographiques de la Synthèse, en ajoutant un paramètre unique listant des AREA_CODE
Noté.
Je préfère une liste de zonages par types de zonages activé.
Pour bien comprendre, tu préfères qu'un seul champ de saisie, et qu'à la saisie on recherche dans tous les types (code type area) listés dans la config ?
Ma solution préférée est, comme dans le Synthèse, un champs par type de zonage :
Donc autant de champs qu'on aurait de AREA_CODE dans le paramètre METADATA_AREA_FILTERS.
Même si ça peut allonger un peu le formulaire de filtre (pas vraiment un soucis selon moi), c'est clair et simple.
Si il est préféré la combinaison de 2 champs (un pour le type de zonage, un pour le zonage du type sélectionné), alors il faut clarifier l'ergonomie et les vocabulaires, pour que l'utilisateur comprenne qu'il doit combiner ces 2 champs, qu'ils vont ensemble, etc...
alors il faut clarifier l'ergonomie et les vocabulaires
Oui c'était indiqué avant la capture car j'avais prévu d'en reparler :
(les labels seront changés)
Je suis plutôt d'accord avec Camille, la cohérence des formulaires de requête me semble la meilleure option ergonomique. Le fait d'avoir un bloc complet Ou? est intuitif et est à privilégier.
