Possibilité de choisir la précision d'affichage des observations selon l'espèce #117
Comments
|
Je devais ouvrir une issue similaire depuis quelques jours également, mais côté GeoNature (pas GeoNature Atlas, car notre Atlas est déjà à la maille). Ceci pour dire que la précision d'affichage devrait être gérée au niveau de la source (GeoNature en l'occurence), car toutes les données d'une espèce dite "sensible" ne sont pas forcément sensibles (les données de Cigogne noire hors nidification sont tout à fait banales, sur des territoires de chasse de plusieurs 10aines de Km²) |
|
Concernant GeoNature, c'est déjà le cas. On peut ensuite filtrer pour ne pas les afficher dans l'atlas dans les critère de la Dans la V2 de GeoNature, on aimerait avoir une notion plus fine et plus conforme au SINP avec des niveaux de sensibilité. Cela permettrait de ne pas diffuser de la même manière certaines observations. Pour le moment c'est archi-basique, soit on diffuse une observation, soit on ne la diffuse pas. L'idée d'avoir certaines espèces affichées au niveau POINT et d'autres au niveau MAILLE ne colle pas vraiment aux textes du SINP mais en terme technique et de lisibilité, c'est la piste la plus simple. Il faudrait juste voir si la liste des espèces (cd_ref) affichées en MAILLE est gérée dans la conf de GN-atlas ou si c'est géré proprement avec un attribut dédié dans TaxHub. |
|
Dans GeoNature V2, un mécanisme de calcul automatique de la sensibilité basé sur les règles (nationales ou régionales) du SINP a été mis en place. La prochaine étape consiste à automatiser son exécution. A partir de ces règles de sensibilité qui définissent automatiquement un niveau de diffusion d'une donnée (à la maille, commune, département...) le PnCévennes a mis en place une fonctionnement dans GeoNature-atlas 1.4. On calcule automatiquement le centroïde de l'objet dégradé (maille, commune...) et on affiche ce centroïde à la place de la localisation précise de l'observation, en précisant qu'il s'agit d'une donnée dégradée. Voir l'exemple sur l'atlas du PnCevennes en zoomant : https://biodiversite.cevennes-parcnational.fr/espece/2645 Plutôt que l'affichage du centroïde, certains souhaiteraient toujours pouvoir choisir le type d'affichage des localisations des observations en fonction de la sensibilité des espèces. |
|
Bonjour à tous, Nous avons commencé à réfléchir à cette question de la gestion de la sensibilité au niveau de l’espèce dans GeoNature Atlas. Il nous semble que différentes pistes assez simples pourraient être envisagées pour afficher à la maille les observations au sein des fiches d’espèces sensibles (propositions 1 à 4). Ces propositions pourraient constituer une première étape en vue d’aborder des questions plus complexes de gestion de sensibilité au niveau de l’observation, notamment d’un point de vue ergonomique pour un rendu cartographique contenant plusieurs niveaux de précision. A noter que pour chacune de ces propositions, la modification ne concerne que l’affichage des observations au sein d'une fiche espèce : l'affichage des observations sur les cartes de la page d'accueil et de la fiche commune ne changent pas (= fonctionnement actuel de l'atlas : point ou maille selon les options choisies dans le fichier de config/settings). Les observations qui contiennent une espèce sensible ne sont simplement pas affichées pour le moment. Proposition 1 : taille de maille unique / liste des espèces en fichier de configuration Cette proposition nous semble être la solution la plus simple. Lorsque l’utilisateur clique sur la fiche d’une espèce protégée, toutes les observations sont affichées à la maille. Toutes les espèces sensibles sont gérées de la même manière, c’est à dire avec une taille unique de maille. Dans le cas d’une espèce non sensible, rien ne change, affichage normal (= fonctionnement actuel de l'atlas : point ou maille selon les options choisies dans le fichier de config/settings). La liste des espèces sensibles est renseignée par une liste de cd_nom dans le fichier de configuration de l’atlas. Exemple : = les observations de lynx et grand tétras seront toutes affichées par mailles de 3x3 dans leur fiche espèce respective. Avantage :
Remarque : par défaut, les tailles de mailles INPN sont 1, 5, 10. Mais si l'administrateur a mis en place une autre taille de maille disponible sur son instance, il pourra l'utiliser pour TAILLE_MAILLE_SENSIBLE (par exemple des mailles de 3x3km). Proposition 2 : taille de maille différentes selon les espèces / liste des espèces en fichier de configuration Identique à la solution 1 mais possibilité d’afficher différentes tailles de mailles selon les espèces sensibles. La liste des espèces sensibles et la taille de maille associée est fournie dans le fichier de configuration de l'atlas Exemple fichier de config : = les observations de lynx seront toutes affichées en maille 5x5km / les observations de grand tétras seront toutes affichées en maille 3x3km. Avantage :
Inconvénient :
Proposition 3 : liste automatisée des espèces sensibles / taille de mailles unique pour les espèces sensibles La différence avec les propositions 1 et 2 est que l'administrateur n'a pas à gérer de liste des cd_nom dans l'atlas. Il faut simplement en amont que la base de données GeoNature soit à jour et fonctionnelle pour les observations sensibles, c'est-à-dire que le schéma gn_sensitivity soit utilisé et à jour. On récupère dans GeoNature Atlas une liste de cd_nom à partir des observations de gn_synthese.synthese qui ont un id_nomenclature_sensitivity qui n'est pas égal à "précision maximale telle que saisie (non sensible)" (SINP). L’obtention de cette liste de cd_nom peut être faite à partir des cd_nom de synthese.syntheseff (modifier légèrement cette vue pour rapatrier également id_nomenclature_sensitivity). L'affichage des espèces sensibles (appartenant à cette liste de cd_nom) pourrait se faire par des mailles dont la taille sera renseignée dans le fichier de configuration de l'atlas : AFFICHAGE_MAILLE_SENSIBLE = True TAILLE_MAILLE_SENSIBLE=n Si l'atlas n'est pas connecté à une base de données GeoNature, il faudra qu'une des tables de la BDD alimentant l'atlas puisse permettre la correspondance entre un cd_nom et une sensibilité. Proposition 4 : liste automatisée des espèces sensibles / tailles de mailles différentes selon les espèces sensibles Comme pour la proposition 3, cette solution permet de se baser sur des données déjà renseignées en amont dans GeoNature ou une autre base de données. On récupère dans GeoNature Atlas une liste de cd_nom à partir des observations de gn_synthese.synthese qui ont un id_nomenclature_sensitivity qui n'est pas égal à “précision maximale telle que saisie (non sensible)". Cette liste de cd_nom d’espèces sensibles peut être stockée dans une table (t_sensitivity_species_rules ?) dans un schéma de GeoNature Atlas ? :
Avantage :
Inconvénient :
Cette solution est plus complexe techniquement car la taille des mailles n'est pas connue au moment de l'installation de l'appli. Il faut donc trouver un moyen de charger efficacement les différents types de mailles pour chaque observation. Peut-être qu'on pourrait modifier légèrement le fonctionnement du chargement des mailles dans la base de données atlas pour avoir seulement un id_maille sensible par id_observation (lorsque l’observation concerne une espèce sensible) dans vm_observations_mailles. Cet id_maille serait sélectionné en fonction des données de la table t_sensitivity_species_rules. Il faudrait détecter chaque changement dans t_sensitivity_species_rules et le répercuter dans vm_observations_mailles. Cette solution nécessiterait par contre de charger tous les types de mailles d’un territoire dans la BDD atlas lors de l’installation. Y a-t-il d’autres possibilités que nous avons oubliées ? Merci pour vos retours ! |
|
Salut Julien, De mon côté, je parlais avec theo la semaine dernière d'un point assez proche. J'aurais bien vu un fonctionnement ou les cartes ne diffusent pas "un point ou une maille" selon la configuration, mais affiche un geom quon lui transmet. Cedt ensuite au niveau de la vm qu'on adapte a nos besoins, pour ne mettre que les centroides, ou que les points précis et les trucs imprécis à la maille, ou tout a la maille etc. Ca permet de gérer tous les cas de figure . Affichage a la maille, au point , a la commune, au site naturel etc selon les besoins de l'utilisateur. Dans notre cas ca permet d'avoir un affichage précis sur certains groupes d'espèces et pas sur d'autres (invertebres précis hors espèces sensibles, tout le reste a la maille par exemple). Libre à chacun ensuite de ne pas balancer sur un même taxon des communes des points des mailles et des polygones pour que l'outil reste lisible par tous les publics... Du coup le paramétrage se ferait au niveau des vm |
|
Nous avons fait une analyse des propositions de @JulienCorny et fait des tests avec @amandine-sahl. Un point n'est pas pris en compte et pose soucis dans les propositions. C'est le fait que lors de la création de la BDD la vue matérialisée qui contient toutes les mailles qui seront ensuite intersectées avec les observations ne correspondent qu'à un seul type de maille : https://github.com/PnX-SI/GeoNature-atlas/blob/master/data/gn2/atlas_ref_geo.sql#L56 Et c'est ensuite avec ces mailles du territoire d'un seul type qu'une autre vue matérialisée est générée avec le nombre d'observation de chaque espèce dans chaque maille est réalisée : https://github.com/PnX-SI/GeoNature-atlas/blob/master/data/observations_mailles.sql#L3 Par ailleurs si on veut réellement s'appuyer sur les règles de sensibilité du SINP intégrées dans GeoNature, alors celles-ci concernant des observations et non pas des espèces directement. Enfin les règles de sensibilité sont des règles définies globalement et collectivement. Donc il s'agit plus de modifier le niveau de diffusion plutôt que le niveau de sensibilité. De plus avec la proposition de Donovan de simplement modifier les vues matérialisées, on a investigué une autre piste avec @amandine-sahl : Adapter la vue matérialisée Exemple à améliorer : -- atlas.vm_observations_mailles source
DROP MATERIALIZED VIEW atlas.vm_observations_mailles;
CREATE MATERIALIZED VIEW atlas.vm_observations_mailles
TABLESPACE pg_default
AS SELECT obs.cd_ref,
obs.id_observation,
m.id_maille,
m.geojson_maille,
m.the_geom,
date_part('year'::text, obs.dateobs) AS annee
FROM atlas.vm_observations obs
JOIN atlas.t_mailles_territoire m ON st_intersects(obs.the_geom_point, m.the_geom)
WHERE NOT cd_ref IN (60612, 2964)
UNION SELECT obs.cd_ref,
obs.id_observation,
m.id_maille,
m.geojson_maille,
m.the_geom,
date_part('year'::text, obs.dateobs) AS annee
FROM atlas.vm_observations obs
JOIN (
SELECT
st_transform(c.geom, 3857)::geometry(MultiPolygon,3857) AS the_geom,
st_asgeojson(st_transform(c.geom, 4326)) AS geojson_maille,
c.id_area AS id_maille
FROM ref_geo.l_areas c
WHERE id_type =28 AND "enable" = true
) m ON st_intersects(obs.the_geom_point, m.the_geom)
WHERE cd_ref IN (60612, 2964)
WITH DATA;
-- View indexes:
CREATE INDEX vm_observations_mailles_cd_ref_idx ON atlas.vm_observations_mailles USING btree (cd_ref);
CREATE INDEX vm_observations_mailles_geojson_maille_idx ON atlas.vm_observations_mailles USING btree (geojson_maille);
CREATE INDEX vm_observations_mailles_id_maille_idx ON atlas.vm_observations_mailles USING btree (id_maille);
CREATE UNIQUE INDEX vm_observations_mailles_id_observation_idx ON atlas.vm_observations_mailles USING btree (id_observation);
-- Permissions
ALTER TABLE atlas.vm_observations_mailles OWNER TO geonatadmin;
GRANT ALL ON TABLE atlas.vm_observations_mailles TO geonatadmin;
GRANT SELECT ON TABLE atlas.vm_observations_mailles TO geonatatlas;Améliorable en créant une table listant les cd_noms à traiter différemment ( WHERE synthese.cd_nom IN (SELECT atlas_excluded.cd_nom
FROM taxonomie.atlas_excluded)Sur la fiche espèce, cela fonctionne :
Sur la page d'accueil aussi :
Il faut quand même vérifier la méthode et la cohérence des données. @amandine-sahl propose aussi de revoir https://github.com/PnX-SI/GeoNature-atlas/blob/master/atlas/modeles/repositories/vmObservationsMaillesRepository.py en intersectant sur
Premiers tests dans une branche dédiée de test : https://github.com/PnX-SI/GeoNature-atlas/compare/test_diffusion_level A faire si on continue dans cette voie :
Voici ce que ça donne en révisant les intersections :
Fiche commune :
Fiche espèce :
A affiner. |
|
Bonjour à tous, Nous avons fait un point avec @amandine-sahl, @AJambon, @camillemonchicourt, @JulienCorny, @Adrien-Pajot et @Julien-Gr4z et voici le compte rendu : Nous avons vu 2 propositions:
La deuxième solution semble la plus intéressante et permet de s'affranchir d'un énième bloc de configuration. Pour l'implémentation de cette 2ème proposition, @amandine-sahl a suggéré de partir de https://github.com/PnX-SI/GeoNature-atlas/blob/master/data/gn2/atlas_synthese.sql et de ne pas calculer et renvoyer le "centroid" de la maille (M10, Commune, Département) mais la maille en elle même. Limitations qui ne pourront pas être contournées :
Du point de vue interface utilisateur :
Merci à vous ! |
L'idée serait plutôt de :
|
|
EDIT :
Bonjour, J'ai pas mal avancé sur la question de la dégradation à la commune et au département. Voici une capture de ce que ça peut donner : On peut masquer certaines mailles avec le bouton en haut à droite : Chemin de la donnée
Si le mode ImplémentationA voir dans la future PR s'il y a.
Limitations de l'implémentation
Est-ce que tout cela vous convient ? |
|
OK merci pour ces éléments. On pourrait anticiper les changements prévus au niveau du SINP de ne plus utiliser de dégradation à la commune ou au départements, mais seulement à des niveaux de mailles distincts, pour plus de cohérence et de simplicité. Pour la méthode, je ne comprends pas tout. Et je comprends pas pourquoi on fait des ST_equals dans vm_observations_mailles, alors qu'on connait déjà l'id de l'objet de dégradation. Mais surement qu'avec la PR cela sera plus clair. |
|
Merci pour ton retour. Pour les changements du SINP, aucun problème, le fait de renvoyer une maille, un département ou une commune n'a pas vraiment d'importance car ce sont des multipolygon donc il n'y a pas d'hypothèses prises là dessus. Les changements seront mineurs. Je t'avoue que je me suis inspiré de ce qu'il y avait déjà dans syntheseff. J'ai juste remplacé la dégradation au centroid par le renvoi de la géométrie réelle si non dégradée et maille/commune/département sinon. Je trouve qu'en renvoyant directement la géométrie dégradée on n'a pas besoin de la dégrader dans vm_observations et dans vm_observations_mailles. Effectivement, très bonne remarque pour l'id, je vais corriger ça. J'essaie de compiler tout ça dans une PR le plus rapidement possible. |
|
Finalement, en regardant de plus près dans la base de données, l'id de l'objet de dégradation n'est pas remonté depuis la syntheseff, c'est pour cela que j'avais opté pour un ST_EQUALS. Je peux changer cela si ça pose problème. |
|
@TheoLechemia a pris le travail de @mvergez (#324) dans la PR #441, pour la simplifier et l'optimiser (notamment en ne faisant pas les intersections trop lourdes entre le observations et les mailles, mais aussi en se limitant aux mailles et sans communes et départements). A noter qu'il reste quelques compléments à faire avant de pouvoir intégrer ça dans une nouvelle version. |
Il serait je pense intéressant de laisser la possibilité de choisir la précision d'affichage des observations naturalistes en fonction de l'espèce, que ce soit au point (X,Y) ou à l'échelle de la maille (1, 5, 10 km). C'est en tout cas un besoin qui émerge pour le parc national du Mercantour et notamment en ce qui concerne les espèces dites "sensibles". Merci
The text was updated successfully, but these errors were encountered: