search

PnX-SI / GeoNature

Application de saisie et de synthèse des observations faune et flore
GNU General Public License v3.0
100 stars 102 forks source link

STATUTS - Gérer la notion de territorialité des différents statuts #793

Open gildeluermoz opened 4 years ago

gildeluermoz commented 4 years ago

Actuellement l'export de la liste des statuts des taxons concernés par le résultat d'une requête repose sur l'ensemble de la table taxonomie.taxref_protection_articles. Or certains taxons ont un statut de protection ou de réglementation dépendant du territoire. Il y a deux chantier. 1/ Faire reposer cet export sur une vue de manière à ce que chacun puisse customiser sa vue et que la table taxonomie.taxref_protection_articles_structure soit utilisée. 2/ Modifier le MCD pour que le statut tienne compte de la localisation des observations.

gildeluermoz commented 4 years ago

cf https://github.com/PnX-SI/TaxHub/issues/157

DonovanMaillard commented 4 years ago

Salut Gil,

Ca renvoie à mon #773 en partie. C'est un chantier sur lequel je compte me pencher dans les prochaines semaines, pour un financement dès 2020 :

L'idée serait en effet de récupérer de l'appli un ensemble d'id_synthèse, et de renvoyer l'info à des vues qui calculeraient les statuts (en fonction de la localisation, donc avoir un geom pour chaque texte par exemple : dans mon cas j'ai des listes rouge auvergne + des listes rouge rhone alpes + les nationales et celles à venir sur la nouvelle région...). Pour la flore on aura des protections départementales etc qui serviront sans doute à d'autres, + les protections liées aux PNx etc. Ca rejoint mon ticket car ce type de vue qui agglomère des infos sans renvoyer un id_synthese=1ligne nous servirait pour citer les sources d'un export, les métadonnées etc en plus des statuts.

Autant d'un point de vue financement je ferai mon possible. Autant du point de vue fonctionnel je veux bien qu'on en discute pour profiter de ton expertise et proposer / faire développer des choses cohérentes et génériques :)

camillemonchicourt commented 4 years ago

Le sujet va au-delà de l'export. Car quand on affiche le détail d'une observation dans la Synthèse, on affiche les protections liées. Donc on a besoin de cette information à différents endroits.

DonovanMaillard commented 4 years ago

oui totalement. Je répondais notamment à la partie export évoquée par gil, mais je pense que la synthèse, et pourquoi pas le dashboard par la suite, pourraient utiliser ce genre d'infos.

jbdesbas commented 4 years ago

Salut, Je vois cette issue un peu tard, mais j'ai commencer à travailler sur le sujet pour un besoin interne assez urgent.

image SQL : https://gist.github.com/jbdesbas/db3fa1290adb595d82874e7f15999860

Le principe général c'est que le territoire peut-être définie au niveau du document et/ou au niveau du statut. Ceci permet par exemple de gérer les listes rouges régionales (ex : région ou dptement comme territoire du document) avec des statuts particuliers pour les sous-populations (ex : communes ou PNR comme territoires du statut). Les fonctions inclues permettent de choisir un statut :

Les documents et statuts n'inclue pas de géométrie, mais une référence vers le référentiel géo (_lareas) car je considère que le statut s'applique toujours sur un territoire référencé (commune, réserve, pnr, etc..)

Je n'en suis pas encore à me préoccuper des performances, mais je pense qu'il pourrait être intéressant de passer par des VM (les statuts étant de toute façon peut changeant).

@DonovanMaillard , selon ce que tu prévois en 2020, ca m'interesserait bien qu'on s'y penche ensemble (et moins dans l'urgence que actuellement pour moi)

camillemonchicourt commented 4 years ago

OK j'ai pas tous les détails, mais c'est surtout à articuler avec le nouveau modèle de la BDD Statuts de l'INPN et faire en sorte de pouvoir calculer automatiquement les statuts locaux en fonction de celle-ci : https://github.com/PnX-SI/TaxHub/issues/157

jbdesbas commented 4 years ago

Tout à fait, le modèle de l'INPN repose également sur le principe document <-> statut (mais avec seulement une référence spatiale pour le document). J'attire toutefois votre attention sur la mauvaise qualité de la BDD statuts de l'INPN qui la rend difficilement exploitable en l'état (exemple rapide, la famille "Gliridea" [199825] apparaît en taxon annexe IV de la DH, avec en commentaire "Toutes les espèces excepté Glis glis et Eliomys quercinus" , ce qui correspond à une traduction littérale, mais pas pertinente, de la directive). La BDD de l'INPN constitue donc une bonne base de départ, mais à retravailler et adapter pour une utilisation dans GeoNature.

camillemonchicourt commented 4 years ago

OK merci pour ces éléments. En complément, je viens de partager un échange que nous avons eu avec l'UMS Patrinat sur la BDC Statuts : https://github.com/PnX-SI/TaxHub/issues/157#issuecomment-568698509

DonovanMaillard commented 4 years ago

Bonjour Jean-Brieuc,

J'ai cerné le besoin, j'ai utilisé la BDC Statuts du muséum, mais n'ai pas encore bien planché sur le mécanisme optimal. Le plus simple sera peut être d'échanger une première fois par téléphone ensemble sur le sujet, et faire un retour ici ?

La BDC est intéressante en effet, et en plus semble bien à jour, mais en effet elle mélange un peu tout. Il y aurait sans doute besoin d'un peu de tri et de regroupements à faire pour un bon usage. Et il faut aussi voir comment l'outil est maintenu à terme. Reste à voir, aussi, que ca doit pouvoir se rattacher au ref geo, qui est propre à chacun...

camillemonchicourt commented 1 year ago

Dans la version 2.11.0 de GeoNature on n'utilise plus les tables caduques comme taxonomie.taxref_protection_articles, mais celles de la BDC statuts du SINP intégrées il y a quelques temps dans TaxHub.

Détail du sujet : https://github.com/PnX-SI/GeoNature/issues/1492

Les textes sont rattachés à une entité géographique et quand on interroge le détail d'une observation, on prend en compte sa localisation pour ne remonter que les textes liés à celle-ci.

Cela est permis grâce au contenu de la table taxonomie.bdc_statut_cor_text_area qui est remplie par cette migration TaxHub : taxonomie.bdc_statut_cor_text_area

Tous les textes définis au niveau national et régional sont remis à plat au niveau départemental, pour éviter des soucis avec les textes de la BDC statuts qui sont encore définis au niveau des anciennes régions, en se basant sur les CD_SIG de l'INPN, fournis dans la BDC statuts.

Tout ça me semble proche de qu'avait indiqué @jbdesbas, mais pas certain que cela permette actuellement d'avoir des textes plus précis à des niveaux plus fins que les départements mais j'imagine que oui.

Pas certain que dans le fonctionnel actuel, si un texte s'applique à un taxon, cela se répercute aussi aux taxons de rang inférieur ?

DonovanMaillard commented 1 year ago

Il y a de belles avancées sur le sujet, merci à vous pour ce boulot !

pnrnm-sig commented 3 months ago

Bonjour, Je déterre le sujet. Il y a un petit bug je crois : avec le peuplement de taxonomie.bdc_statut_cor_text_area on a plus les statuts mondiaux et européen. Les statuts nationaux sont bien copiés par départements mais pas les statuts internationaux, si j'ai bien compris (ligne 130-140)

texts AS (
            SELECT -- Si 'TERFXFR', 'ETATFRA' insertion de tous les départements
            bst.id_text,
            la.id_area
            FROM taxonomie.bdc_statut_text AS bst,
            ref_geo.l_areas AS la
            WHERE la.id_type = ref_geo.get_id_area_type('DEP')
            AND bst.cd_sig IN ('TERFXFR', 'ETATFRA')
            UNION
            SELECT DISTINCT -- Si département
            bst.id_text,

J'ai corrigé en effectuant les requêtes suivantes :

update taxonomie.bdc_statut_text
set enable = true 
where cd_sig in ('EUROPE','WORLD');

INSERT INTO taxonomie.bdc_statut_cor_text_area (id_text, id_area)
SELECT 
  bst.id_text,
  la.id_area
FROM taxonomie.bdc_statut_text AS bst, ref_geo.l_areas AS la
WHERE la.id_type = ref_geo.get_id_area_type('DEP')
AND bst.cd_sig IN ('EUROPE', 'WORLD');