Possibilité de choisir la précision d'affichage des observations selon l'espèce

[samuelpriou]

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

[sig-pnrnm]

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).
J'ai en effet une donnée de nidification de Cigogne noire qui n'a pas été intégrée à GeoNature pour qu'aucun photographe naturaliste ne soit tenté d'aller photographier l'oiseau.

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²)

[camillemonchicourt]

Concernant GeoNature, c'est déjà le cas.
Un champs diffusion (oui/non) a été ajouté dans la synthèse dans GeoNature 1.8.0 (https://github.com/PnX-SI/GeoNature/releases).
Et dans la 1.9.0, ce champs a été ajouté dans chaque protocole et est saisissable observation par observation (dans le ContactFaune et Mortalité, pas encore dans les autres).

On peut ensuite filtrer pour ne pas les afficher dans l'atlas dans les critère de la atlas.vm_observations : https://github.com/PnEcrins/GeoNature-atlas/blob/master/data/atlas.sql#L33

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.
Cependant il semble compliqué et peu lisible pour une même fiche de représenter des observations de manière différente.

Pour le moment c'est archi-basique, soit on diffuse une observation, soit on ne la diffuse pas.
Idem pour les espèces, on peut ne pas diffuser TOUTE une espèce en la filtrant dans le WHERE de la atlas.vm_observations.

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.

[camillemonchicourt]

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.
Par exemple utiliser un maillage 1kmx1km pour la plupart des espèces (tel que cela est actuellement sur notre atlas) et utiliser un maillage plus important (3x3 km ou 5x5 km) pour les quelques espèces sensibles du territoire.

[JulienCorny]

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 :

AFFICHAGE_MAILLE_SENSIBLE = True 

TAILLE_MAILLE_SENSIBLE = 5 

LISTE_TAXONS_SENSIBLES = [60612, 2964] 

= les observations de lynx et grand tétras seront toutes affichées par mailles de 3x3 dans leur fiche espèce respective.

Avantage :

• Simple et rapide
• Pas de liste d'espèces sensibles à gérer en base de données
• Pas de différence si l'atlas est connecté ou non à une base de données GeoNature

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 :

AFFICHAGE_MAILLE_SENSIBLE = True 

LISTE_TAXONS_SENSIBLES = [{'60612':'5'}, {'2964':'3'}] 

= 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 :

• Simple car pas non plus de gestion de base de données
• Pas de différence si l'atlas est connecté ou non à une base de données GeoNature

Inconvénient :

• Fastidieux pour l'administrateur
• Pas aussi clair et lisible qu'une table en BDD

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 ? :

• Colonne cd_nom
• Colonne max_id_nomenclature_sensitivity qui permet d'indiquer l'id_nomenclature_sensitivity dont la valeur est la plus élevée pour le cd_nom concerné : par exemple si un cd_nom est représenté par 12 observations dans la gn_synthese.synthese et que les valeurs de id_nomenclature_sensitivity pour les observations concernées vont de 0 à 3, on indiquera 3 dans max_id_nomenclature_sensitivity.
• Colonne taille_maille : on peut indiquer une taille de maille par défaut identique pour tous les cd_nom (par ex à partir d'une variable du fichier de configuration TAILLE_MAILLE_SENSIBLE_DEFAUT). Cette colonne pourra être modifiée par l'administrateur pour permettre un affichage de taille de maille personnalisable selon les espèces.

Avantage :

• Gestion simple pour l'administrateur car s'appuie en partie sur la gestion en amont de la sensibilité dans la BDD GeoNature
• Clair et transparent (pas de liste de cd_nom difficilement lisible en configuration)
• Taille des mailles personnalisables
• Prépare à des solutions plus complexes dans le futur pour la gestion de l’affichage pour la sensibilité au niveau des observations

Inconvénient :

• Nécessite une BDD GeoNature (ou autre) à jour en amont concernant la sensibilité des données

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 !

[DonovanMaillard]

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

[camillemonchicourt]

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
L'application ne dispose donc qu'un seul type de maille.

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.
Là le besoin est plutôt d'avoir un niveau de diffusion plus dégradé que ce que préconise le SINP.

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 atlas.vm_observations_mailles pour qu'elle tape sur les mailles par défaut pour la pluppart des espèces, sauf pour une liste de cd_nom pour laquelle elle taperait dans d'autres types de mailles directement dans la table ref_geo.l_areas.

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 (taxonomie.atlas_excluded dans cet exemple) et en les retrouvant dynamiquement dans le WHERE :

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 vm_observations_mailles plutot que vm_observations

• Et pour les fiches communes et la Home, elle propose d'intersecte avec t_mailles_territoires, pour renvoyer les id_mailles de toutes les petites mailles de la grande maille.

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 :

• Bugs des doublons de la page d'accueil
• Optimisation des requêtes
• Correction (cas où les mailles ne coïncide pas totalement)

Voici ce que ça donne en révisant les intersections :

Fiche commune :

Fiche espèce :

A affiner.

[mvergez]

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:

1. Utiliser les scripts dans les commentaires ci-dessus et gérer la sensibilité de l'observation de manière indépendante dans l'atlas (via, par exemple, la création d'une nouvelle table définissant la sensibilité)
2. Se servir du diffusion_level du schéma gn_synthese et des tables du schéma gn_sensitivity de geonature pour récupérer la sensibilité de l'observation. Ceci implique l'ajout du champ diffusion_level dans la vm.observations de l'atlas.

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 :

• Pouvoir afficher les observations sous forme de point et sous forme de maille
• Afficher les observations contenues dans la maille de 10km dans le cas où l'utilisateur cliquerait dans une maille de 5km contenue dans celle de 10km

Du point de vue interface utilisateur :

• Les mailles de 10km et de 5km ont les mêmes propriétés graphiques. Il faudrait les modifier pour l'une d'entre elles pour pouvoir les distinguer comme montré sur l'image attachée
  

• Il serait intéressant d'ajouter une option pour afficher uniquement les mailles de 5km et celles de 10km

Merci à vous !

[amandine-sahl]

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.

L'idée serait plutôt de :

1. Dans la table syntheseff : avoir la géométrie exacte, le niveau de dégradation (diffusion_level) et à voir le lien vers la géométrie de dégradation
2. Dans la table vm_observations : dégrader la géométrie au centroid de la zone de dégradation. Pour le moment il n'a pas été envisagé de mélanger les affichages point et polygones.
3. Dans la table vm_observations_mailles : prendre en compte le niveau de dégradation pour avoir la bonne taille de maille. Se pose la question des données dégradées à la commune, utilise t'on de grandes mailles?

[mvergez]

EDIT :

• Éclaircissement du mode AFFICHAGE_MAILLE et de la maille de 1km²
• Ajout limitation sur les centroid

---

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

1. t_mailles_territoire : regroupement de tous les types de géométries (mailles 1km² et 10km², communes, département) intersectant le territoire et non toute la France. Récupération de l'id_type de l_areas pour pouvoir distinguer des mailles.
2. Syntheseff : récupération de la sensibilité et renvoi de la géométrie correspondante (maille 10km², commune, département et maille 1km si pas de sensibilité) et non du centroid
3. vm_observations_mailles : récupération des observations dont la géométrie correspond à une géométrie de t_mailles_territoire (st_equals) + récupération de l'id_type de la maille
4. mapGenerator.js : en fonction de l'id_type, ajout dans un featureGroup pour pouvoir masquer les types de mailles

Si le mode AFFICHAGE_MAILLE=False et si l'observation est sensible, on prend le centroid de la géométrie dans vm_observations sinon on prend le point exact.

Implémentation

A voir dans la future PR s'il y a.
En résumé :

• modification des scripts de génération des vues précédentes
• modification dans le backend pour récupérer les id_type
• modification du js pour pouvoir masquer/afficher les types de géométries

Limitations de l'implémentation

• Les observations précises (au point) sont dégradées à la maille de 1km² dans vm_observations_mailles. Donc impossible de mélanger point et maille sur une même carte
• L'affichage dans la fiche espèce peut devenir difficilement exploitable (sans désactiver les layers), car la sensibilité est au niveau de l'observation et non de l'espèce (géométries dégradées différentes pour une même espèce)
• Pas de clusterisation si beaucoup d'observations. Cela semble néanmoins possible de regrouper des multipolygons avec MarkerCluster. A voir...
• t_mailles_territoire inclue aussi les mailles frontalières avec le territoire, c'est corrigeable
• En mode AFFICHAGE_MAILLE=False pas de regroupement si les observations se trouvent au même centroid (même maille)

Est-ce que tout cela vous convient ?

[camillemonchicourt]

OK merci pour ces éléments.
Pour l'affichage ça fonctionne pas mal en effet.

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é.
Mais ça peut aussi être fait dans un second temps.

Pour la méthode, je ne comprends pas tout.
Notamment du fait qu'on avait plutôt retenu de garder la géométrie d'origine dans syntheseff, et de récupérer l'éventuelle géométrie dégradée que dans vm_observations (au centroïde) et dans vm_observations_mailles.
Mais peut-être que ce fonctionnement n'est finalement pas possible ou adapté ?

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.

[mvergez]

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.

[mvergez]

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.