Feat/extended-areas#446
Conversation
They are not used an raises errors and warnings from sqlalchemy
In order to make them compatible with API, and to return data in the same format as communes.
For search, to get all geometries and types
Which is like ficheCommune but for any area
Remove filter in bib_areas_types => not very useful
Had to add an argument to the autocomplete function so that it can take
the type of the geo the user wants to search for
Had geostats to existing stats
Had a new function to compute global geo stats in one query
(select
sum(case when vbat.type_code = 'MyType1' then 1 else 0 end) AS count1,
sum(case when vbat.type_code = 'MyType2' then 1 else 0 end) AS count2
FROM atlas.vm_l_areas vla
join atlas.vm_bib_areas_types vbat on vbat.id_type = vla.id_type)
Restrict area codes: filter out the query to search and the one that returns geoms Taxon list interaction now works with the AreaSheet
|
J'ai finalement ajouté un paramètre |
And exclude M1,M5,M10,COM (COM must be removed when vm_l_areas will be used for COM also)
|
J'ai un warning sur une query : Sur cette fonction : GeoNature-atlas/atlas/modeles/repositories/vmAreasRepository.py Lines 380 to 397 in 87b9ff6 Si quelqu'un a déjà eu ce warning je suis preneur ! |
Unfix the warning because it introduced a bug...
|
A voir comment aborder ce sujet car Gil avait aussi initié un travail similaire sur 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. De mémoire aussi, il ne faut pas qu'on garde un SQL générique et un spécifique |
|
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.
Ici l'objectif était seulement de faire fonctionner la notion de "Fiche Zone". |
Instead of syntheseff because it takes to much time
So that it can be like the others (species sheet...)
And move grant
6a024a8 to
3703408
Compare
In the case of taxoRankSheet
|
Oui, intéressant. OK pour moi. |

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.sqlvm_bib_areas_types: Pas de filtre sur lestype_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 unwhere st_intersectssur le territoire (cela permet d'avoir toutes les zones à disposition et plus tard se servir del_areaspour les communes !). Tout en gardant unwhere enable=true. Qu'en pensez-vous ?vm_cor_area_observation: nous ne nous basons plus sursynthese.cor_area_synthesemais nous faisons l'intersection nous même dans la vue matérialisée (viasyntheseffetvm_l_areas). Cela permet par exemple de changer facilement de zones à mettre en avant dans l'atlas sans avoir à recalculer lecor_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
/area) qui peut prendre comme filtresearch(recherche surarea_nameetarea_code) ettypepour filtrer sur le type de zones (utilisé dans Quelques chiffres, voir plus bas) et pourra plus tard être utilisé pour les communes./area/geom) utilisée uniquement pourarea.html(voir ci-dessous).Ajout d'une route template
render_templatele templateareaSheet.htmlafin d'accéder à la Fiche Zone.Templates html
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...
areas.html.sample(donc à activer ou non via le paramètreSTATIC_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.code_type(voir configuration) :Configuration
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 : untype_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 garderEXTENDED_AREApour 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ésactivableAjout des traductions associées
Ce qu'il reste à faire :
atlas_with_extended_areas.sqldans le script d'installation. Paramétrer son appel ? Lié à la question précédentesurrounding_areasdans la Fiche ZoneProchains 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 !