Open babastienne opened 2 months ago
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
Sur le floutage :
Côté GNA :
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.
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:
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).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.@camillemonchicourt sur la carte qui affiche les observations floutées, est-ce pertinent de conserver les boutons de couche en checkbox (voir capture) ou faut-il passer sur des radio-boutons pour éviter de superposer des couches qui n'ont pas de sens d'être affichées les unes sur les autres ?
Je suis plutôt d'avis d'avoir des radio-buttons. Tu as un avis ?
Pour moi il faut clairement pouvoir afficher toutes les données ensemble, en parallèle et qu'elles soient toutes actives par défaut.
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 ;
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 :
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.