-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feat/extended-areas #446
base: develop
Are you sure you want to change the base?
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.sql
vm_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_intersects
sur le territoire (cela permet d'avoir toutes les zones à disposition et plus tard se servir del_areas
pour les communes !). Tout en gardant unwhere enable=true
. Qu'en pensez-vous ?vm_cor_area_observation
: nous ne nous basons plus sursynthese.cor_area_synthese
mais nous faisons l'intersection nous même dans la vue matérialisée (viasyntheseff
etvm_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_name
etarea_code
) ettype
pour 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_template
le templateareaSheet.html
afin 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_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ésactivableAjout des traductions associées
Ce qu'il reste à faire :
atlas_with_extended_areas.sql
dans le script d'installation. Paramétrer son appel ? Lié à la question précédentesurrounding_areas
dans 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 !