Feat/extended-areas

[mvergez]

Contexte

Dans le cadre d'une prestation avec la LPO PACA, ce travail fait suite à celui effectué en grande partie par @lpofredc sur la problématique "Fiche Zone" ("Area sheet"). Cette problématique avait été reprise puis certaines fonctionnalités avaient été désactivés car non fonctionnelles à l'époque. Cette PR est la continuité des discussions faites ici : #438

Travail effectué

Nous avons essayé de nous appuyer sur ce qui a déjà été fait. Merci à vous @lpofredc et ceux qui ont contribué, vous nous avez bien facilité la tâche. Voici ce qui a été fait et les décisions prises :

Revue de atlas_with_extended_areas.sql

• vm_bib_areas_types : Pas de filtre sur les type_code : cela complique la chose pour au final filtrer une liste de maximum 50 types de zones...
• vm_l_areas : ce n'est pas encore implémenté mais je pensais à juste mettre un where st_intersects sur le territoire (cela permet d'avoir toutes les zones à disposition et plus tard se servir de l_areas pour les communes !). Tout en gardant un where enable=true. Qu'en pensez-vous ?
• vm_cor_area_observation : nous ne nous basons plus sur synthese.cor_area_synthese mais nous faisons l'intersection nous même dans la vue matérialisée (via syntheseff et vm_l_areas). Cela permet par exemple de changer facilement de zones à mettre en avant dans l'atlas sans avoir à recalculer le cor_area_synthese (alimenté par trigger à chaque insertion dans la synthèse). De plus, selon nous, cela rend peut-être plus simple l'utilisation de l'atlas sans un GeoNature.

  Ajout de 2 routes API

  • Une pour la recherche ou pour avoir la liste de toutes les areas (/area) qui peut prendre comme filtre search (recherche sur area_name et area_code) et type pour filtrer sur le type de zones (utilisé dans Quelques chiffres, voir plus bas) et pourra plus tard être utilisé pour les communes.
  • Une renvoyant toutes les géométries (/area/geom) utilisée uniquement pour area.html (voir ci-dessous).

Ajout d'une route template

• Ajout d'une route pour render_template le template areaSheet.html afin d'accéder à la Fiche Zone.

Templates html

• Reprise de la recherche multi zones : la recherche se fait toujours via une modale mais seule une barre de recherche est mise à disposition pour rechercher sur tous les types de zones renseignés dans la configuration : A voir s'il ne faudrait pas mettre la barre de recherche à côté des barres de recherche sur les taxons et communes. La modale semble un peu vide...
• Ajout d'une page areas.html.sample (donc à activer ou non via le paramètre STATIC_PAGES) permettant d'afficher une carte avec les zones. Le fonctionnement est identique à https://atlas.cbiodiv.org/landscape, donc le code s'inspire beaucoup (merci encore @lpofredc). Utilise notamment la route /area/geom.
• Ajout de la possibilité d'ajouter des statistiques sur les zones avec une barre de recherche associée filtrant sur le code_type (voir configuration) :

Configuration

• Ajout de GLOBAL_GEO_STATS : permet d'ajouter les statistiques sur les zones dans "En quelques Chiffres..." comme montré ci-dessus. Il est possible de renseigner une liste de zones en procurant pour chacune d'elle : un type_code, un nom à afficher et un picto.
• EXTENDED_AREA : nous pensons mettre une liste de zones pour restreindre la recherche sur les types de zones choisis. Ou alors le garder tel quel et ajouter un paramètre afin de garder EXTENDED_AREA pour activer/désactiver la recherche sur les zones. Quelle est la stratégie là-dessus ? Activer la fonctionnalité sur toutes les zones par défaut dans l'atlas ? Ou la rendre désactivable

Ajout des traductions associées

Ce qu'il reste à faire :

• [x] Ajout d'un paramètre pour restreindre la recherche aux types renseignés grâce à ce paramètre.
• [x] Appeler le script atlas_with_extended_areas.sql dans le script d'installation. Paramétrer son appel ? Lié à la question précédente
• [x] Regarder la fonctionnalité de surrounding_areas dans la Fiche Zone
• [x] Regarder le problème de l’interaction liste/carte qui ne fonctionne pas
• [x] Relire le code, ajouter des commentaires, formater avec black et supprimer les variable/fonctions/modules non utilisés

Prochains développements

L'objectif de cette PR est aussi de poser la base sur, selon nous, un futur développement : la généralisation des zones pour y inclure les communes. Cette PR étant déjà conséquente, nous ne voulions pas non plus faire trop de changements en profondeur. Nous verrons si nous avons la possibilité de nous en occuper.

Merci d'avance pour vos retours !

[mvergez]

J'ai finalement ajouté un paramètre AREAS_LIST qui attend une liste de area_codes. Il permet de restreindre la recherche de zones et les géométries renvoyées (routes API area et area/geom).

[mvergez]

J'ai un warning sur une query :

vmAreasRepository.py:416: SAWarning: SELECT statement has a cartesian product between 
FROM element(s) "anon_1" and FROM element "atlas.vm_l_areas".  
Apply join condition(s) between each element to resolve.

Sur cette fonction : https://github.com/PnX-SI/GeoNature-atlas/blob/87b9ff619dace628296f86425983a3ec1ed44556/atlas/modeles/repositories/vmAreasRepository.py#L380-L397

Si quelqu'un a déjà eu ce warning je suis preneur !

[camillemonchicourt]

A voir comment aborder ce sujet car Gil avait aussi initié un travail similaire sur https://github.com/PnX-SI/GeoNature-atlas/compare/develop...gildeluermoz-blagnac

De mémoire, il me semble pertinent de ne plus forcément avoir la notion de communes en dur, mais de pouvoir définir un ou plusieurs types de zonages venant du ref_geo que l'on souhaite faire remonter au niveau recherche mais aussi au niveau des fiches espèces. A voir si on garde et comment la possibilité de déployer un GeoNature-atlas sans GeoNature.

De mémoire aussi, il ne faut pas qu'on garde un SQL générique et un spécifique atlas_with_extended_areas.sql, mais le sujet est un peu loin et flou pour moi.

[mvergez]

Merci pour ton retour @camillemonchicourt !

Oui j'ai regardé, mais comme spécifié dans la (trop longue) description, je pense qu'il faudra procéder à cette étape de généralisation des zones (pour absorber les communes) dans un second temps. Sinon la PR va devenir illisible à mon sens. Car il faudrait :

• Prendre en compte les travaux de Gil
• Supprimer pas mal de code côté back + template + sql
• Voir où sont renseignées les communes "en dur" (exemple: fiche espèce, recherches, quelques chiffres etc...).
• Tout en gardant quand même une notion de commune pour les usagers de l'atlas
• Sûrement d'autres choses => ça fait pas mal de boulot et beaucoup de contenu à la PR.

Ici l'objectif était seulement de faire fonctionner la notion de "Fiche Zone".

[Naomi-Fischer]

Bonjour, Afin d'optimiser l'affichage des différentes barres de recherches et ameliorer l'UX, nous vous proposons cette version pour le header : Il y aurait une barre de recherche unique triant par défaut les recherches par espèces, et pouvant être modifiée simplement depuis un select visible sur le coté. Cela réduirait le nombre de champs/boutons, et éviterai de masquer dans une modale les autres types de filtres, facilitant ainsi l'utilisation pour les utilisateurs. Qu'en pensez-vous ?

[camillemonchicourt]

Oui, intéressant. OK pour moi. Attention à ce que ça fonctionne bien aussi en mobile.