Revoir et finaliser le floutage SINP

[babastienne]

Amandine avait développé un premier truc qui est intégré dans le code depuis pas mal de versions en faisant des centroides. Donc pas vraiment basé sur le standard SINP.

Puis Natural Solutions S a développé un vrai truc de floutage SINP des observations. Théo a ensuite reprise développement et celui-ci était basé sur la 1.4. Entre temps d'autres ont bossé sur une version 1.5 mais sans la sensibilité qui n'était pas abouti/mergé. On avait discuté ça ici notamment : https://github.com/PnX-SI/GeoNature-atlas/issues/117#issuecomment-1256130077 Depuis ça a divergé et d'autres ont fait des PR sur le sujet avec d'autres approches. Ici par exemple il me semble : https://github.com/PnX-SI/GeoNature-atlas/issues/390

---

Complément BPO

Pour des raisons réglementaires, il est important de pouvoir mettre en place un floutage des observations à l’échelle du territoire dans un souci de protection des espèces. Il s’agit là d’un besoin déjà exprimé à plusieurs reprises par la communauté GeoNature mais à ce jour non implémenté, qu’il conviendra donc de mettre en œuvre.

Toutefois, pour implémenter cette demande cela nécessite de trancher fonctionnellement et techniquement plusieurs points, en particulier ;

• En termes de données : comment calculer le niveau de floutage ? GeoNature expose plus de données que la simple correspondance espèce ↔ taille maille et le degré de sophistication du floutage n’a pas été décidé par la communauté ;
• Faut-il permettre le floutage au niveau de l’observation ? Cela reviendrait à permettre plusieurs niveaux de floutage au sein d’une même espèce. Cet élément ajoute une complexité dans la conception mais une plus grande finesse d’affichage ;
• Cela soulève également plusieurs questions non tranchées au niveau de l’affichage dans GeoNature-Atlas, en particulier sur comment afficher une carte avec plusieurs espèces (par exemple les dernières observations) et donc potentiellement plusieurs niveaux de maille simultanés, l’outil n’étant actuellement pas prévu pour cet usage. Des pistes ont été abordées dans la communauté mais pour le moment aucun axe n’a été avancé pour permettre de conjuguer les observations sous forme de point et de maille sur une même carte ;

Ces questions ne concernent pas directement l’OBM du fait de ses spécificités (correspondante simple définie par l’arrêté en lien de l’exigence, cartographie globale en carte de chaleur plutôt que dernières observations), cependant la conception doit être terminée globalement en tenant compte de GeoNature pour pouvoir faire accepter les développements complémentaires sur le dépôt de GeoNature-Atlas.

De plus, il faudra tenir compte de la spécificité du module d’installation de GeoNature-Atlas pour Nantes Métropole qui n’utilise pas le reste de la solution GeoNature et ne bénéficie donc pas d’un certain nombre de modules associés.

En l’état, la solution qui semble le plus faire l’unanimité auprès de la communauté est celle implémentée dans la pull request ouverte suivante : GeoNature-Atlas#441. Après échange avec le Parc National des Écrins nous avons eu confirmation que ce travail devait être repris et approfondi en particulier pour proposer une méthodologie adaptée pour les installations sans GeoNature.

Nous proposons donc, en partant de cette PR qui implémente un fonctionnement correspondant à l’exigence de Nantes Métropole (limitation de l’affichage de certaines espèces à une maille 10x10 km ou interdiction de diffusion), d’effectuer des améliorations en accord avec l’architecture souhaitée par le Parc National des Écrins sur les axes suivants :

• Reprise du code existant, consolidation et ajout de tests unitaires ;
• Adaptation dans l’interface du comportement d’affichage, optimisations graphiques sur la cartographie ;
• Reprise de la procédure d’installation et des scripts associés, mise en place d’une migration de données ;
• Ajout d’une procédure détaillée pour le mode d’installation sans GeoNature, compatible avec les vues exploitées par GeoNature pour ne pas avoir à maintenir deux mécanismes différents en parallèle.

Cette exigence fait partie des éléments du cahier des charges représentant la plus important complexité d’implémentation. Il conviendra donc de valider précisément les besoins associés ainsi que les implications fonctionnelles et techniques avant de mettre en place l’architecture logicielle définitive à valider avec le Parc National des Écrins, mainteneur du projet. Plusieurs échanges seront mis en place pour traiter ce point.

[pchapuis-nantesmetropole]

Pour info et à titre d'exemple, l'arrêté préfectoral des Pays de la Loire : https://www.pays-de-la-loire.developpement-durable.gouv.fr/resultats-et-arrete-prefectoral-regional-a5221.html

[babastienne]

Sur le floutage :

• Il existe une liste nationale d'espèce protégée et pour chaque espèce il y a un caractère de diffusion
• A l'échelle régionale ces règles peuvent être "surchargées"
• Parfois la complexité va au-delà de simplement l'espèce, mais peut être lié à la temporalité (date de l'observation, est-ce qu'il s'agit d'une observation de l'espèce ou de l'habitat, etc.)
• Ce travail de floutage est déjà bien réalisé dans GeoNature

Côté GNA :

• Travail réalisé partiellement, à reprendre. Il faut comprendre ce qui a été fait et le finaliser. https://github.com/PnX-SI/GeoNature-atlas/pull/441
• La problématique est surtout dans la représentation cartographique. Par défaut il faut pouvoir afficher des mailles de 500m mais dans le cas de certaines réglementations de précision supérieures il faut que la maille puisse être adaptée (pour devenir par exemple 10km).
• Sinon l'autre question à poser c'est est-ce qu'on représente tout simplement les données qui sont à des mailles 10x10 ?
• Actuellement c'est GNA qui transforme les points en maille. Si on a des observations communales on prend le centroid de la commune et on applique une maille à l'emplacement du centroid. GNA sait donc traiter des données précises pour les représenter à une échelle de maille.
• En revanche GNA ne sais pas représenter des données déjà imprécises.

Voir aussi https://github.com/PnX-SI/GeoNature-atlas/issues/117

A faire pour le moment côté MC : analyser le code déjà réalisé sur la PR ouverte et les tickets existants. Puis faire une réunion technique dédiée avec PNE/PNC/NM/MC.

[jpm-cbna]

Je confirme qu'il faut repartir de la PR #441 qui a intégré une partie des développements de ma PR390. La prise en compte du floutage en fonction du niveau de diffusion de la PR #390 n'est plus nécessaire car il ne s'applique plus dans le cadre du SINP.

Par contre, il y a de nouvelles nomenclatures pour la sensibilité à prendre en compte:

cd_nomenclature	mnemonique	label_default	definition_default
2.1	M1	1 km²	1 km² soit 100 hectares soit Maille 1 km.
2.2	M2	4 km²	4 km² soit 400 hectares soit Maille 2 km.
2.3	M5	25 km²	25 km² soit 2500 hectares soit Maille 5 km.
2.4	M10	100 km²	100 km² soit 10 000 hectares soit Maille 10 km.
2.5	M20	400 km²	400 km² soit 40 000 hectares soit Maille 20 km.
2.6	M50	2500 km²	2500 km² soit 250 000 hectares soit Maille 50 km.
2.7	M70	5000 km²	5000 km² soit 500 000 hectares.
2.8	M0	Aucune diffusion	Aucune diffusion.

J'ai adapté ma PR #390 pour supprimer la vue syntheseff en générant directement la VM vm_observations à l'image de la PR #441 tout en tenant compte des nouvelles nomenclatures sensibilité. Voir mon commentaire dans la PR#441 pour accéder au travail réalisé.

Les problèmes que je rencontre avec la mise en place de ces nouvelles nomenclatures sont:

• l'augmentation très importante du nombre de lignes dans la table cor_area_synthese (à cause des nouvelles mailles) qui ralentie la génération de la VM correspondante dans l'Atlas (1h pour 29 millions de données).
• le temps de génération de la VM vm_observations qui est également très long. L'intersection nécessaire pour calculer le code INSEE de la commune de chaque observation est une des sources de ralentissement.