Skip to content
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

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

Open
gildeluermoz opened this issue Nov 12, 2019 · 12 comments
Open

Comments

@gildeluermoz
Copy link
Contributor

gildeluermoz commented Nov 12, 2019

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 gildeluermoz changed the title STATUTS - faire porter l'export sur une vue STATUTS - Gérer la notion de territorialité des différents statuts Nov 12, 2019
@gildeluermoz
Copy link
Contributor Author

cf PnX-SI/TaxHub#157

@DonovanMaillard
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor

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
Copy link
Contributor

jbdesbas commented Dec 23, 2019

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 :

  • soit a partir d'un taxon, document et geométrie (optionnelle)
  • soit à partir d'un taxon, type de document (LRR, protection, etc..) et géométrie (optionnelle)
    Le système permet aussi de gérer les statuts des taxons inférieurs (hérités du statut du taxon supérieur).

Les documents et statuts n'inclue pas de géométrie, mais une référence vers le référentiel géo (l_areas) 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
Copy link
Member

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 : PnX-SI/TaxHub#157

@jbdesbas
Copy link
Contributor

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
Copy link
Member

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 : PnX-SI/TaxHub#157 (comment)

@DonovanMaillard
Copy link
Contributor

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
Copy link
Member

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 : #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
Copy link
Contributor

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

@pnrnm-sig
Copy link

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');

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants