Atlas par mailles communales

[sig-pnrnm]

Bonjour à tous,

Notre Atlas n'est pas encore officiel, mais les réflexions pré-ouverture avancent.

Parmi celles-ci, le choix d'un affichage par mailles a été retenu, mais plutôt que des mailles régulières (5Km, 1Km, ...), ma hiérarchie et nos élus souhaitent un affichage par mailles communales. D'un point de vue géomatique, il y a des avantages et des inconvénients, et dans l'idéal, plutôt que de choisir entre les deux, il serait vraiment super de pouvoir basculer d'un mode à l'autre. Je l'ai fait dans quelques développements Leaflet parallèles à GeoNature [*], et ça marche assez bien auprès des publics testés.

Voici une petite démo, sans données, d'un bouton intégré dans une carte Leaflet, juste pour montrer que ça peut être très discret (ne pas surcharger l'interface) : http://jsfiddle.net/ozLnodsc/ (et encore, je suis nul en CSS, j'ai juste utilisé la bibliothèque Toggle Switch)

Il faudrait ajouter une vm_observations_communes pour que ça fonctionne.

Qu'en pensez-vous ?

[*] Comparaison mailles communales / mailles 1Km (les 2 sont complémentaires)

[sig-pnrnm]

Encore plus discret/petit sans texte (puisque les "tooltip" affichent la fonction du bouton) : http://jsfiddle.net/23pmy0rt/

[Splendens]

Bonjour, Pour notre projet d'atlas des Pays de la Loire, on nous demande également une restitution par mailles et par communes. Merci pour cette piste ! Effectivement les boutons peuvent être discrets.

[camillemonchicourt]

Hum hum, si mon prof de cartographie voyait ça il ferait des bonds ! :-) Représenter une information sur des objets de surface variable fausse l'information. Certaines communes sont très grandes et d'autres sont petites. Du coup on représente des informations similaires sur des objets de surface très variable...

Autre point d'attention, pour que la bascule entre AFFICHAGE COMMUNAL ou par MAILLE soit rapide et réactif, cela veut dire qu'il faut charger les limites des communes ainsi que les observations côté client. Et pour utiliser le slider, il faut utiliser toutes les observations, pas seulement un calcul global. Voir https://github.com/PnEcrins/GeoNature-atlas/issues/53 Du coup, ça risque d'alourdir le chargement de la page mais aussi la réactivité du navigateur de l'utilisateur. Il faudrait ajouter la géométrie des mailles et leur nombre d'observations au geojson téléchargé pour chaque fiche. Exemple pour le chamois : http://biodiversite.ecrins-parcnational.fr/api/observationsMailleAndPoint/61119 Sinon quand on switche, il faudrait relancer un appel serveur.

Pour ne pas imposer cela, il faut donc imaginer un système générique, activable/désactivable pour ceux qui ne souhaiteraient pas utiliser/proposer un affichage communal.

[sig-pnrnm]

Hum hum, si mon prof de cartographie voyait ça il ferait des bonds ! :-)

C'est bien ce que j'ai essayé d'expliquer, mais mes arguments n'ont pas tenu face à la demande "politique". Et malgré tout, d'un point de vue "appropriation / sensibilisation", j'entends cette demande : l'echellon communal et un échellon important d'analyse, surtout dans les PNR. On pourrait imaginer représenter sous forme de ponctuels, avec variation de taille/couleur des points, mais des tests que j'ai fait c'est moins "lisible" (bien que plus "juste" d'un point de vue carto...).

Autre point d'attention [...] charger les limites des communes

C'est clair qu'avec le Slider qui multiplie les géométries, c'est un point important. Au dela du fait d'optimiser son fonctionnement, ce qui serait certainement plus lourd (mais ce serait bien de ce pencher là dessus un jour), de mon côté, j'utilise une requête SQL pour simplifier les géométries des communes, tout en préservant leur topologie. Voir cette page qui l'explique : https://trac.osgeo.org/postgis/wiki/UsersWikiSimplifyPreserveTopology et mon message sur GeoRezo qui le fait sur une couche de commune de GeoNature : https://georezo.net/forum/viewtopic.php?id=107301 (requête du 3e message).

Pour ne pas imposer cela, il faut donc imaginer un système générique, activable/désactivable pour ceux qui ne souhaiteraient pas utiliser/proposer un affichage communal.

C'est tout à fait l'idée !

En espérant qu'on puisse avancer là dessus ! :) (j'ai du "budget de développement" normalement, donc peut-être le prioriserons nous sur ce point)

A+

Sylvain

[camillemonchicourt]

En fait j'ai dit une bêtise dans l'autre ticket. Les géométries des mailles ne sont pas dupliquées par autant qu'il y a d'observations dans chaque maille mais ajouter les communes va forcement grossir pas mal le geojson. A moins de faire un appel serveur quand on bascule d'un mode d'affichage à l'autre.

[DonovanMaillard]

Bonjour à tous,

Je ne suis pas fan de cet affichage par commune, mais il est vrai que c'est a priori quelque chose que les utilsateurs aiment voir (en tous cas dans le milieu naturaliste associatif).... Par contre, est-ce qu'on pourrait pas rester justes dans nos mathématiques, et ne pas afficher un nombre de données, mais une densité? (nombre de données par kilomètre carré pour une commune). Quitte à faire du sig en ligne, on peut même imaginer un nombre de données total dans la commune quand on la survole?

Mathématiquement c'est juste. Pour orienter les prospections c'est plus juste également (sinon clairement dans quelques années les petites communes, qui apparaitront toutes en jaune, auront un meilleur effort de prospection pour compenser cette fausse "sous prospection", notamment quand les utilisateurs sont d'un milieu associatif (on s'appuie souvent sur de telles cartes pour cibler les zones où aller).

Donovan

[Splendens]

A moins de faire un appel serveur quand on bascule d'un mode d'affichage à l'autre.

Oui, des appels AJAX permettraient de charger les géométries "à la demande", et cela éviterait d'avoir à charger d'emblée un gros fichier geojson.

j'utilise une requête SQL pour simplifier les géométries des communes, tout en préservant leur topologie.

C'est une bonne idée pour alléger le geojson, mais tu simplifie les géométries après avoir agrégé les données à la maille communale ?

[sig-pnrnm]

Par contre, est-ce qu'on pourrait pas rester justes dans nos mathématiques, et ne pas afficher un nombre de données, mais une densité? (nombre de données par kilomètre carré pour une commune). Quitte à faire du sig en ligne, on peut même imaginer un nombre de données total dans la commune quand on la survole?

Tu as été plus rapide que moi Donovan, c'est ce que je comptais proposer ce matin (suite à mes reflexions nocturnes ;) ) Je vais tenter sur mes interfaces parralèles une légende basée sur "Nb d'observations par Km²"

C'est une bonne idée pour alléger le geojson, mais tu simplifie les géométries après avoir agrégé les données à la maille communale ?

L'idée serait de stocker, dans ta table des communes, un champ geom_simpli calculé une fois pour toutes, et utilisé uniquement pour les rendus en GeoJSON (via ST_AsGeoJSON).

[camillemonchicourt]

L'idée de la densité par commune est mieux en effet même si tout ça tout ça devient compliqué pour le public visé.

Attention aussi quand vous parlez de pression d'observation et d'effort de prospection. Ce n'est pas la vocation de l'outil ni le public visé. Cette partie est à gérer côté GeoNature.

Il est prévu un module Prospections dans GeoNature, surtout ne pas refaire la même chose dans GeoNature-atlas qui deviendrait vite compliqué et trop technique alors que sa force est justement d'être simple.

On mélange à nouveau les publics et les vocations de chaque outil.

[DonovanMaillard]

Tout à fait d'accord avec toi camille, en fait je ne mettrais aucune de ces cartes sur l'atlas mais dans geonature, de base. Car si elles sont disponibles, elles seront forcément utilisées à ces fins par le milieu naturaliste... en fait je pense qu'il ne faut pas mettre ces cartes, mais que si elles sont effectivement rendues disponibles car demandées, il faut au moins éviter les fausses interprétations et donc représenter une densité...

Celà dit, la meilleure réponse est peut être tout simplement d'orienter les utilisateurs vers les fiches communes. Les politiques peuvent savoir combien il y de données sur leur commune, combien d'espèces connues etc. Et pour une vision plus globale, elle est plutôt demandée ponctuellement, et à produire par le PNR au cas par cas ou à avoir coté geonature...

[sig-pnrnm]

On mélange à nouveau les publics et les vocations de chaque outil.

Je ne suis pas d'accord Camille : dans notre cas (que je pense partagé par beaucoup de PNR), la restitution à l'échelle communale n'est justement pas à destination du public "naturaliste", mais bien du "grand public", et même en particulier le "public élus", dont l'échelle communale est la plus parlante. Les mailles (carrées ou autre) ne parlent justement pas beaucoup à ce public, qui n'est pas familier des notions cartos.

L'idée de la densité par commune est mieux en effet même si tout ça tout ça devient compliqué pour le public visé.

Il suffit de continuer à afficher "Nombre d'observations", mais de préciser "par Km²" en petit quelque part, ou au survol par la souris.

Et dans tous les cas, quand on clic sur la commune, on affiche la valeur brute, et non la densité. Du coup, la carte est "juste d'une point de vue carto", et "compréhensible par les élus".

En fait, pour replacer dans le contexte de notre Observatoire, j'ai justement proposé pas mal d'analyses par mailles. Et le retour de ma hierarchie et de nos élus est qu'ils ont besoin d'analyses par communes pour mieux comprendre leur territoire.

[camillemonchicourt]

Quand je parlais de publics et de vocations, je parlais au sujet de la notion de réparation des prospections. Mais aussi globalement de compliquer l'outil avec des switch etc etc. Je ne parlais pas des communes. Nous aussi la commune est un repère fort pour les habitants, les touristes, les élus. C'est pour ça qu'on a mis en avant des fiches par communes. :-)

[sig-pnrnm]

C'est pour ça qu'on a mis en avant des fiches par communes. :-)

Oui, et elles sont très bien ! Mais, pas d'Atlas communal. Et ça, c'est LA demande de mes élus/hierarchie ;)

[camillemonchicourt]

Je comprends pas, un atlas communal, ce sont des fiches par commune avec toutes les espèces observées sur chaque commune, non ?

Bref, comme je disais au début, pas de soucis pour ajouter un affichage par commune sur les fiches espèces si c'est désactivable/générique. La notion de densité est plus complexe mais plus intéressante. La question de l'appel serveur est plus sur en terme de performance mais ça sera un peu long quand on passera d'un affichage à l'autre.

[sig-pnrnm]

Je comprends pas, un atlas communal, ce sont des fiches par commune avec toutes les espèces observées sur chaque commune, non ?

Je voulais parler d'un Atlas de l'ensemble des communes : pour avoir une vision plus globale du territoire.

pas de soucis pour ajouter un affichage par commune sur les fiches espèces si c'est désactivable/générique. La notion de densité est plus complexe mais plus intéressante.

Cool alors, je pensais que tu ne trouvais pas ça pertinent ! L'idée est bien que ce soit générique et désactivable ! :)

ça sera un peu long quand on passera d'un affichage à l'autre.

Je t'envoi en mail perso une interface qui permet de permutter affichages communes / mailles, et tu verras que c'est tout à fait fluide (moins d'une secondes à chaque changement).

[sig-pnrnm]

Suite à la discussion avec Camille par téléphone, j'ajoute un 3e mode au petit bouton sur la carte : le mode "observations précises". http://jsfiddle.net/344nmv5p/ En effet, pour les structures qui choisissent un affichage des localisations précises, basculer du mode "observations précises" au mode "analyse par maille" (qu'elle soient carrées et/ou communales) ajoute une dimension d'analyse statistique supplémentaire (ce que ne permettent pas les localisations précises).

Chacun de ces 3 modes pourraient bien-sûr être (des)activable ou non.

[camillemonchicourt]

Oui actuellement, le basculement entre les 3 modes de présentations (maille, clusters, points) est automatisé en fonction du nombre d'observations de l'espèce et du niveau de zoom. Les seuils de bascule entre les affichages sont paramétrables mais on a souvent évoqué la possibilité pour l'utilisateur de pouvoir forcer un affichage à n'importe qu'elle échelle. Du coup c'est en effet à regrouper avec l'affichage par maille communale.

[sig-pnrnm]

Camille, je ne sais pas trop où partager ce bout de code, ni si ça a un intérêt ici (tu me le dis, et je le retire), mais voici la requête SQL qui permet depuis la table layers.l_communes de créer une table l_communes_simpli200 avec une simplification topologique à 200m.

(je n'ai pas créé de nouveau champ dans la BDD GeoNature, car je ne veux pas modifier la structure de GeoNature. J'ai mis dans un schéma pnrnm indépendant)

CREATE TABLE pnrnm.l_communes_simpli200 AS
with poly as (
        select insee, (st_dump(the_geom)).* 
        from layers.l_communes
) select d.insee, baz.geom 
 from ( 
        select (st_dump(st_polygonize(distinct geom))).geom as geom
        from (
                select (st_dump(st_simplifyPreserveTopology(st_linemerge(st_union(geom)), 200))).geom as geom
                from (
                        select st_exteriorRing((st_dumpRings(geom)).geom) as geom
                        from poly
                ) as foo
        ) as bar
) as baz,
poly d
where st_intersects(d.geom, baz.geom)
and st_area(st_intersection(d.geom, baz.geom))/st_area(baz.geom) > 0.5;

CREATE INDEX sidx_l_communes_simpli200 ON pnrnm.l_communes_simpli200 USING gist (geom);

(inspiré de https://trac.osgeo.org/postgis/wiki/UsersWikiSimplifyPreserveTopology)

Sur une base communale 2500 communes, la requête met près de 4 minutes à s'executer, d'où l'intérêt de pré-calculer ces géométries simplifiées topologiques. La capture d'écran ci-dessous montre la simplification obtenue avec 200m en paramètre (meilleur compromis fluidité/précision chez nous).

[camillemonchicourt]

Impec

[DonovanMaillard]

Je pense que ce genre de traitement des données sur l'atlas posera des soucis selon les échelles... 4 minutes pour 2500 communes, si on utilise l'outil pour un niveau national ça coincera... De même, des communes avec des formes particulières auront des soucis de traitement, on voit déjà Le champ de la pierre qui perd un pourcentage pas négligeable de ce qu'on en voit ici... pas sur que la simplification soit si avantageuse et générique

[sig-pnrnm]

Je pense que ce genre de traitement des données sur l'atlas posera des soucis selon les échelles... 4 minutes pour 2500 communes, si on utilise l'outil pour un niveau national ça coincera...

Comme je le disais, c'est un traitement à ne lancer qu'une seule fois pour toutes ! Donc 4 minutes pour 2500 communes représente 57 minutes de traitement sur la base nationale. Rien d'insurmontable pour PostGis, et aucune perte de fluidité pour l'appli puisque le calcul n'est refait qu'en cas de changement de la base communal (certe, c'est fréquent en ce moment avec les fusions de communes).

on voit déjà Le champ de la pierre qui perd un pourcentage pas négligeable de ce qu'on en voit ici...

Tu ne vois qu'un bout du Champ de la Pierre, mais en réalité, la communes est tout à fait visible dans l'appli (désolé, je ne peux donner le lien pour l'instant, mon serveur n'est pas "officiel").

J'ai fait le point sur l'ensemble de ma région Normandie + départements Pays de la Loire, et je n'ai aucun souci de communes problématiques. Si des communes font moins de 200m de "rayon total", peut-être que ça coincerait, mais il y a certainement moyen d'optimiser la requête pour ces rares cas.

[camillemonchicourt]

Un travail a été réalisé par @Splendens pour permettre d'afficher les observations par maille ou par commune et de basculer entre les 2 affichages :

Notamment avec ce commit dans sa fork : https://github.com/Splendens/atlas_biodiv_pdl/commit/297b52424c1379aa69e14022027f59d9fbe57e00

Mais aussi avec des commits ajoutant les éléments nécessaires dans la BDD.

A voir comment le réintégrer dans le dépôt de GeoNature-atlas, tout comme d'autres évolutions intéressantes réalisées dans cette fork : https://github.com/Splendens/atlas_biodiv_pdl/commits/master

[Splendens]

Et switch avec l'affiche en points également ! Avec le choix de ce qu'on veut comme affichage (point et/ou maille et/ou commune) grâce à des paramètres dans le fichier de configuration.

J'ai un fork de GN-atlas, je vais ajouter toutes les modifs dedans pour pouvoir faire une PR. C'est un peu embêtant de devoir "faire le travail deux fois de suite", mais les fonctionnalités demandées pour le projet en Pays de la Loire commencent à s'éloigner de l'esprit de GN-atlas...

[sig-pnrnm]

C'est super tout ça !!! Bravo Marie !!! :+1:

Une petite suggestion cosmétique : plutôt que d'ajouter 3 boutons, qui permettent de switcher d'un mode de représentation à l'autre, ce serait plus épuré avec 1 seul bouton de type switch. (cf. le bouton que j'avais proposé sur ce JSFiddle)

Mais c'est un détail ! :sunglasses:

[laurentbarthe]

Bonjour à tous, Un premier et rapide message en espérant que c'est le lieu de poster ce type de retours car suis vraiment néophyte sur ce type d'outils... Nous sommes en train d'installer et travailler sur une application de l'outil atlas pour un rendu des données naturalistes à l'échelle de l'Occitanie et parmi les premiers retours du réseau on retrouve systématiquement cette absence du rendu à l'échelle communale. Malgré les biais liés à ce rendu, c’est l’échelle qui fait l’unanimité de tous les publics utilisateur pour avoir des vu d’ensemble (hors pointage précis) : élus, aménageurs, touristes, élèves, habitants d’un territoire mais aussi producteur de données qui fonctionnent désormais aussi bien par mailles que par commune.

Pour info si ça peut servir. Dans les développements liés à ce rendu, nous avons quelques besoins qui reviennent souvent et notamment une « bulle informative » quand on passe avec sur la commune avec : Commune ; nombre de données ; Date dernière obs ; observateur ; Source de la donnée et quand on passe sur une commune vide la possibilité d’avoir quand même le nom de la commune. Au plaisir d’échanger avec vous.

[camillemonchicourt]

OK @Splendens , merci pour les précisions sur les options d'affichage et le switch configurable.

On avait imaginé avoir un fonctionnement automatique (niveau de bascule entre maille et point puis entre clusters et points), en ajoutant la possibilité à l'utilisateur de forcer un affichage à n'importe qu'elle niveau. Du coup on s'en approche. On regardera ça prochainement.

Pour les PR, cela te faciliterait peut-être les choses si tu avais une branche par fonctionnalité, que tu merges régulièrement dans la ton Master. Ça serait ainsi bien plus simple d'isoler la partie correspondant à l'affichage des mailles communales pour en faire une PR.

Concernant ton projet d'atlas qui diverge de plus en plus de l'esprit de GN-atlas, la solution est peut-être de la centrée sur les besoins de base et de travailler les besoins avancés plutôt côté GeoNature, destiné aux membres de la structures, aux partenaires etc...

@laurentbarthe , bienvenue, c'est tout à fait l'endroit pour échanger, merci pour ton retour.

Comme pour les mailles, il y a aussi une tooltip quand on clique sur une commune :

[laurentbarthe]

Ok, super. Merci Camille. Hâte de voir cette option sur notre version alors.

[Splendens]

Bonjour, ça fait un bon moment que je n'avais pas remis les pattes dans cet affichage par mailles communales...

Du coup, je m'excuse par avance s'il y a des redites dans ce post !

Je voudrais faire une PR pour la fonctionnalité d'affichage d'atlas par mailles communales, mais j'ai quelques interrogations...

• Dans l'affichage par maille communale, il y a l'affichage des organismes dans le tooltip lorsqu'on clique sur une maille. J'ai fait une PR à ce sujet en juillet dernier (https://github.com/PnX-SI/GeoNature-atlas/pull/157). Est-ce qu'il vaudrait mieux que j'attende que cette PR soit évaluée ? Ou que je fasse une autre branche avec les mailles communales sans l'affichage des organismes sources ?

• Qui dit affichage par mailles communales, dit "mailles communales". Je ne sais pas comment faire pour ce point : je mets une note avec une méthode pour générer des mailles communales simplifiées ? Ou bien il faudrait mieux générer des communes simplifiées à l'échelle française et faire une sélection spatiale lors de l'installation de GN-atlas (comme pour les grilles) ?

• L'affichage par mailles communales est calqué sur celui des grilles. Pour un petit nombre de données (testé jusqu'à un million et quelques de données), ce type d'affichage fonctionne. Par contre, aujourd'hui Biodiv'Pays de la Loire approche des 3 millions de données, et si l'affichage par mailles carrées passe encore (avec des lenteurs...), celui par mailles communales ne passe plus du tout. La récupération des mailles prends beaucoup trop de temps. Donc là, je me demande s'il faut mettre des warning, ou s'il faut repenser complètement la façon de récupérer les données pour les cartes...

• Pour la généricité, j'ai mis en place des paramètres pour le choix de l'affichage ou non du switch mailles communales / carrées. Mais bon, comme je le dit on point précédent, lorsqu'il y a beaucoup de données il faut mieux juste désactiver le switch.

Vous en pensez quoi ?

ps : @camillemonchicourt Oui ce projet d'atlas diverge de plus en plus de l'esprit de GN-atlas (et rend les MàJ compliquées !)... Le bon côté, c'est que grâce au nombre croissant de données pour cet atlas des PdL, cela permet de tester les limites de l'outil ;) @laurentbarthe Vous avez combien de données à afficher en Occitanie ? Des retours sur l'affichage des cartes en grilles avec plusieurs millions de données également ?

[laurentbarthe]

Bonjour, Je ne comprends pas pourquoi tu dis que ce projet diverge de plus en plus de l'esprit GN-atlas ? Personnellement, je trouve qu'il permet justement d'avoir de plus en plus d'options que l'on peut / ou pas installer sur son propre Atlas. Aujourd'hui toutes les structures qui travaillent à une échelle supra de la commune sont demandeuses d'un rendu à la commune. C'est indispensable pour une bonne appropriation (action de sensibilisation) du grand public et c'est très utile pour orienter facilement les besoins de prospection. Pour le moment, pour Occitanie nous devons encore jongler entre webobs et GN-atlas… Sur notre outil, nous en sommes à 1 722 180 mais Romain Baghi pourra mieux expliquer la partie technique car pour nous il s’agit d’interroger chaque nuit d’autres bases de données qui alimentent cet outil. En tout cas, pour le moment ça ne rame pas trop mais je sais que c'est l'inquiétude permanente de Romain...

[camillemonchicourt]

Oui le fait de pouvoir basculer entre affichage communal ou à la maille est une évolution intéressante. Super si tu peux faire une PR. Un important travail est en cours pour rendre GeoNature-atlas compatible avec GeoNature V2 et pas mal d'autres choses sont faites en même temps : https://github.com/PnX-SI/GeoNature-atlas/compare/1.3.2...develop L'affichage des organismes devrait en faire partie, donc ta PR était bienvenue et doit être calée avec la compatibilité GN2. Selon moi tu peux faire ta PR d'affichage communal, en lien avec cette PR qui ajoute les organismes. Et on devra combiner tout ça. On devra aussi combiner ça avec https://github.com/PnX-SI/GeoNature-atlas/pull/178 en cours.

Bon, l'afficher sous forme d'aplat de couleur alors que les surfaces des communes sont très variables est une faute en cartographie (discuté plus haut).

C'est un peu plus complexe mais beaucoup plus juste, voici comment l'affichage du nombre de taxons par commune est affiché sur https://www.sigogne.org/carto/ :

OK pour rester sur des aplats de couleur pour le moment, mais il est important de pouvoir désactiver cette fonction d'affichage pour ceux qui ne souhaitent pas l'utiliser (choix fonctionnels ou performances)

Le problème de performance avec l'affichage par maille est identifié et lié au slider (https://github.com/PnX-SI/GeoNature-atlas/issues/53), donc charger en plus les communes de la même manière (données dupliquées pour chaque observation) fait en effet exploser le problèmes. Les limites de commune étant bien plus lourdes que celles des mailles. A améliorer avant ou alors il faut supprimer le SLIDER par année, au cœur du problème ?

Simplifier les géométries pour leur affichage est une bonne piste, mais ce serait mieux de pas (trop?) les simplifier pour les intersections avec les données.

Sur le fait de dériver de l'esprit initial de GeoNature-atlas, l'affichage par commune reste un besoin grand public. Tant qu'on reste simple, qu'on ne fait un WebSIG (on est à la limite là) et que les fonctionnalités sont activables/désactivables, on reste dans le périmètre.

Mais on souhaite que l'outil reste simple d'utilisation, qu'il ne cible pas en premier les experts, techniciens, mais bien plus large priorisant le grand public.

Donc clairement, tout ce qui est plus technique, plus pointu, à destination des naturalistes, des membres d'un réseau, des personnes qui saisissent a bien plus sa place dans GeoNature. Par exemple tout ce qui concerne l'identification de la pression d'observation n'a pas sa place dans GN-atlas mais bien dans GN.

C'est dans ce sens qu'on a amorcé le développement du module Tableau de bord de GeoNature qui remplira cette fonction : https://github.com/PnX-SI/gn_module_dashboard/issues/2 On réfléchit d'ailleurs à ce que celui-ci (ainsi que des modules de GeoNature comme la Synthèse) puissent être rendus consultables sans authentification.

A suivre.