MCD Synthese - Githubissues

camillemonchicourt commented 7 years ago

Les principes proposés sont les suivants :

Se baser sur le standard INPN Occurrences de taxons mais en le rendant plus permissif et en passant les champs liés à des nomenclatures en varchar. Notamment pour pouvoir y intégrer des données non saisies dans GeoNature (partenaires, historiques...)
Proposer des valeurs par défaut pour ces champs en se basant sur les nomenclatures INPN (valeurs les plus courantes ou plutôt Non renseigné ?

gildeluermoz commented 7 years ago

Le unique_id_sinp a une valeur par défaut, donc s'il n'est pas fourni à l'insertion, la base en créé un : A discuter/valider @camillemonchicourt : Ca me semble bien. Mais discutable car il peut s'agir d'une donnée transmise mais sans son unique_id alors qu'il en avait bien un dans sa BDD source ?
Pas d'organism_owner, organism_producer... dans la synthèse car on les retrouve via la fk id_dataset sur t_datasets qui comporte les infos (cela veut dire qu'il n'est pas possible d'insérer des données dans la synthèse sans créer au préalable un jeu de données). @camillemonchicourt : OK pour moi.
Pour le moment pas de NOT NULL sur tous les champ en FK des id_nomenclature mais un DEFAULT = (Ne sait pas ou inconnu selon ce qui est dispo en nomenclature) : A discuter/valider @camillemonchicourt : OK ça impose de bien garder les mêmes ID localement.
Pas de FK pour le id_municipality (on considère qu'il peut y avoir des données en synthèse sans correspondance dans la table des communes) : A discuter/valider @camillemonchicourt : Je vois pas pourquoi il n'y aurait pas de communes pour certaines observations, mais ça simplifie pour ceux qui sauraient pas le calculer en base ? Et quid des observations avec N communes ? A voir si on garde qu'une dans la SYNTHESE ? En tout cas ça colle avec le principe que la synthèse est plus permissive que les champs des protocoles.
Pour être occurrence de taxon compatible, j'ai conservé les 6 champs du cor_counting_contact : sexe, age, type de dénombrement, objet dénombré et count min et max : A discuter/valider @camillemonchicourt : Ouais je suis pas convaincu par le fait de dupliquer les observations pour chaque dénombrement. Je garderai qu'un effectif total mais pourquoi pas.
Pas de FK pour le cd_nom (on considère qu'il peut y avoir des données en synthèse sans correspondance dans la table taxonomie.taxref) : A discuter/valider Donc le cd_nom n'a pas de NOT NULL on peut donc créer une observation sans taxon (est-ce que je mets une contrainte pour vérifier que si cd_nom IS NULL alors nom_cite IS NOT NULL ?). Au passage on oubli le id_nom qu'on ambitionne de supprimer : choix important à discuter/valider @camillemonchicourt : A fond pour commencer à se débarasser du id_nom, au moins en ne le remettant pas dans GeoNature. Pas de FK sur le CD_nom ça va dans le sens d'une SYNTHESE permissive mais ça se discute car c'est assez dangereux et peu exploitable. Ceux qui ajoutent leurs propres taxons doivent quand même les mettre dans TAXREF avec un cd_nom temporaire type 9999999985, non ?
Pour le moment les observers sont en string 255. Est-ce qu'on casse la mise à plat de la synthese pour faire une cor_synthese_role_observer ou cor_synthese_observer ? Mon point de vue est qu'en synthèse on s'en sort très bien avec des string et que lors de l'insertion de jeux de données externes, s'il faut créer d'abord tous les observateurs, on s'en sortira pas. @camillemonchicourt : Ca me semble OK aussi pour la Synthese.
Idem pour determinator @camillemonchicourt : Oui.
J'ai mis la determination_method en synthèse : A discuter/valider @camillemonchicourt : Pas d'avis.
Un seul comment où on concaténera les différents commentaires (relevé et/ou occurence pour le contact par ex) @camillemonchicourt : Oui on avait évoqué ça dans un ticket.
Pas de sample_number_proof en synthèse @camillemonchicourt : Et si c'est la synthèse qui est le support des exports SINP, alors on aura plus cette info attendue par le SINP ?
Pas trop compris la différence entre les nomenclatures 5 et 16 (je vous laisse étudier le truc et en choisir une). Pour le moment j'ai mis les 2 dans la synthèse mais il faudra je pense en retirer une. Attention, il y a aussi une nomenclature 17 (sensible = oui ou non)... Dont je ne sais pas trop quels sont les usages et traductions fonctionnels possibles. Cette nomenclature 17 n'est pas en place dans la synthèse pour le moment. @camillemonchicourt : Pas regardé.
Une table t_modules (ex bib_sources) permet de faire des références vers les schémas internes à la base pour savoir où sont garées les données sources. A voir si on la renomme t_sources mais l'idée est bien qu'elle soit dans le schema synthese car elle décrit le contenu de la table synthese. Je me demande toujours si elle fait pas doublon avec t_protocoles où on pourrait aussi avoir cette info, non ? Ou alors ça colle pas toujours ... ? @camillemonchicourt : Je ne suis pas sur que le terme MODULES colle bien avec ce que contient cette table et son usage. Je pense que SOURCES parle plus, même si les choses ne sont toujours limpides pour moi entre t_datasets, t_programs, t_protocols et t_sources.
Manque la table synthese.cor_synthese_unitegeo pour faire le lien entre chaque données de la synthèse avec une ou pls (lignes et polygones) unité(s) géographique(s). @camillemonchicourt : Oui et à voir comment on gère ça maintenant qu'on a ref_geo

MERCI DE REPONDRE A CHACUN DES POINTS PAR UN SEUL COMMENTAIRE EN REPRENANT LA DISCUSSION

gildeluermoz commented 7 years ago

Globalement, il faut choisir entre 1/ une synthèse custom GeoNature 2/ une synthèse répondant au mieux à la norme occurrence de taxon.

Je pencherais pour l'option 2.

gildeluermoz commented 7 years ago

_Pour être occurrence de taxon compatible, j'ai conservé les 6 champs du cor_countingcontact : sexe, age, type de dénombrement, objet dénombré et count min et max : A discuter/valider @camillemonchicourt : Ouais je suis pas convaincu par le fait de dupliquer les observations pour chaque dénombrement. Je garderai qu'un effectif total mais pourquoi pas.

Si on souhaite une compatibilité avec l'occurrence de taxon et un modèle de la synthese à plat, on n'a pas trop le choix, il faut respecter la norme donc avoir plusieurs enregistrements en synthese pour l'observation d'un même taxon. Si on ne souhaite pas faire ça, il faut faire un truc un peu tordu : casser le modèle à plat de la synthese et faire une table nn cor_counting_synthese sur le modèle du cor_counting_contact (on devrait le faire pour les communes par exemple), donc pourquoi pas. Et mettre dans la table synthese un total_count; ce qui permet d'utiliser soit la table nn, soit le total_count, soit les 2 selon le besoin. POINT IMPORTANT A TRANCHER RAPIDEMENT ! MERCI

gildeluermoz commented 7 years ago

_Pas de sample_numberproof en synthèse @camillemonchicourt : Et si c'est la synthèse qui est le support des exports SINP, alors on aura plus cette info attendue par le SINP ?

Ok, c'est fait : https://github.com/PnX-SI/GeoNature/commit/7f82aff2f638096eb0c2e3e1dbdc6ec590608cf2

gildeluermoz commented 7 years ago

_Pas de FK pour le idmunicipality (on considère qu'il peut y avoir des données en synthèse sans correspondance dans la table des communes) : A discuter/valider @camillemonchicourt : Je vois pas pourquoi il n'y aurait pas de communes pour certaines observations, mais ça simplifie pour ceux qui sauraient pas le calculer en base ? Et quid des observations avec N communes ? A voir si on garde qu'une dans la SYNTHESE ? En tout cas ça colle avec le principe que la synthèse est plus permissive que les champs des protocoles.

Ce que dit la norme SINP occurrence de taxon : Le rattachement ou le géoréférencement à la commune est OBLIGATOIRE CONDITIONNEL : Il DOIT être fait si aucune autre information (objetGeo, Departement, EspaceNaturel, Maille, MasseDEau) n'est remplie.

En synthese, on aura donc le cas rattachement et le cas géoréférencement. Je propose :

pas de champs id_municipality dans la table synthese.
une table nn cor_municipality_synthese (id_synthese, id_municipality, ref_name, ref_version, typeInfoGeo) comme décrit par la norme. Le typeInfoGeo est égal par défaut à géoréférencement mais il peut être égal à rattachement dans le cas de données anciennes rattachées à la commune. A voir si on utilise rattachement dans le cas de données dont la sensibilité indique que la diffusion doit être faite à l'échelle de la commune. Sur ce point, il faut penser que selon l'utilisateur identifié dans GeoNature, il faudra localiser les observations de manière différenciée (en synthèse et dans les modules). Il faudra donc que l'information décrivant le mode de représentation soit facilement utilisable : A discuter

https://github.com/PnX-SI/GeoNature/commit/bb2d80706220b7064dbbbff2d7d77c656e71f375 A voir si c'est utile et si ce n'est pas un doublon avec cor_area_synthese qui contient les communes

gildeluermoz commented 7 years ago

Un seul comment où on concaténera les différents commentaires (relevé et/ou occurence pour le contact par ex) @camillemonchicourt : Oui on avait évoqué ça dans un ticket.

A noter que c'est plus ou moins compatible avec la norme...

gildeluermoz commented 7 years ago

_Une table t_modules (ex bib_sources) permet de faire des références vers les schémas internes à la base pour savoir où sont garées les données sources. A voir si on la renomme t_sources mais l'idée est bien qu'elle soit dans le schema synthese car elle décrit le contenu de la table synthese. Je me demande toujours si elle fait pas doublon avec t_protocoles où on pourrait aussi avoir cette info, non ? Ou alors ça colle pas toujours ... ? @camillemonchicourt : Je ne suis pas sur que le terme MODULES colle bien avec ce que contient cette table et son usage. Je pense que SOURCES parle plus, même si les choses ne sont toujours limpides pour moi entre t_datasets, t_programs, t_protocols et tsources.

Ok pour revenir à t_sources : https://github.com/PnX-SI/GeoNature/commit/aff3720d619c718a9087aec9507f739eee5271ff Pour clarifier :

t_sources = notion interne à GeoNature; Permet de faire le rattachement de l'observation de synthese avec son enregistrement dans un schéma de la base. S'il la données n'existe qu'en synthese c'est qu'elle doit venir d'une source externe (enregistrement en synthese via une API par exemple). dans ce cas, la donnée a pour source une valeur générique par défaut (par exemple id=0 name='donnée externe')
t_datasets = point d'entrée vers les métadonnées des observations regroupées au sein d'un jeu de données ayant des points communs.
t_programs = regroupement des jeux de données au sein de programmes ayant un caractère thématique, scientifique et/ou programmatique.
t_protocols = à définir. Liens à faire avec tout ce qui concerne le contexte de recueil des données. Cela peut recouper : la notion de protocole dans CAMPANULE, la notion de protocole au sein des PNx (question posée, méthode, date_debut, date_fin, etc...). La notion de protocole n'est pas implémentée dans la base GeoNature V2 pour le moment. Il faut à priori attendre le développement prévu par l'afb sur le sujet.

gildeluermoz commented 7 years ago

_Manque la table synthese.cor_synthese_unitegeo pour faire le lien entre chaque données de la synthèse avec une ou pls (lignes et polygones) unité(s) géographique(s). @camillemonchicourt : Oui et à voir comment on gère ça maintenant qu'on a refgeo

Plusieurs propositions, 1/ lien fixé avec ref_geo.l_grids. Dans ce cas on fige les unités geo en maille. 2/ on supprime l_grids et on met le maillage INPN dans l_areas. 3/ on créé une table vm_unites_geo et chacun met dedans ce qu'il veut (duplication des geom dans la VM lors du refresh mais une seule source à maintenir) 4/ comme la norme occurrence de taxon prévoit un lien de rattachement ou de géoréférencement à différentes unités géographiques (départements, communes, mailles, masse d'eau, espaces protégés), on met toutes ces unités géographiques dans une même table comme prévu dans l_areas et on fait une cor_area_synthese.

Cette proposition 4, la plus ambitieuse mixe les propositions 2 et 3 et reprend le principe de cor_municipality_synthese (id_synthese, id_area, ref_name, ref_version, typeInfoGeo) en instaurant une intersection systématique avec toutes les géométries du ref_geo.l_areas. Dans ce cas, il faut aller jusqu'au bout de la démarche et supprimer l_grids et l_municipalities : on garde l_municipalities_additional que l'on renomme simplement l_municipalities qui serait une fille de l_areas avec une FK id_municipalilty pointant sur id_area et forcement pas de geom puisqu'il serait dans la table l_areas. A voir si on garde une table l_grids pour tout ce qui est calcul à partir des bounds.

Voir un début de mise en œuvre de la proposition 4 : https://github.com/PnX-SI/GeoNature/commit/d8b1f966b2f71ac1ddad9357679728e22bcf3aa2

gildeluermoz commented 7 years ago

_Pas de FK pour le cd_nom (on considère qu'il peut y avoir des données en synthèse sans correspondance dans la table taxonomie.taxref) : A discuter/valider Donc le cd_nom n'a pas de NOT NULL on peut donc créer une observation sans taxon (est-ce que je mets une contrainte pour vérifier que si cd_nom IS NULL alors nom_cite IS NOT NULL ?). Au passage on oubli le id_nom qu'on ambitionne de supprimer : choix important à discuter/valider @camillemonchicourt : A fond pour commencer à se débarasser du id_nom, au moins en ne le remettant pas dans GeoNature. Pas de FK sur le CD_nom ça va dans le sens d'une SYNTHESE permissive mais ça se discute car c'est assez dangereux et peu exploitable. Ceux qui ajoutent leurs propres taxons doivent quand même les mettre dans TAXREF avec un cdnom temporaire type 9999999985, non ?

Ok pour se débarraser du id_nom dans GeoNature2. On peut tenter de mettre une FK dans la synthese mais pas de NOT NULL + la contrainte CHECK IF cd_nom IS NULL THEN nom_cite IS NOT NULL. On a ainsi au moins la garantie de pouvoir identifier le taxon de l'observation. Ceci permet aussi pour ceux qui le souhaite d'ajouter un cd_nom temporaire dans taxonomie.taxref sans que ce soit obligatoire. Sinon on peut aussi mettre un NOT NULL sur nom_cite et l'affaire est réglée sans contrainte CHECK. https://github.com/PnX-SI/GeoNature/commit/0c09a69dc3e4c05200a4f096f38aee7a4bb0b62e

camillemonchicourt commented 6 years ago

Evolutions :

camillemonchicourt commented 6 years ago

Gil a en effet travaillé sur la SYNTHESE :

comparaison synthese <--> moduleocctax pour être sur que tout ce qui est pertinent pour la synthèse dans occtax ne manque pas dans la synthèse.
comparaison synthese <--> référentiel inpn occurrence de taxon. Pour voir où on en est de l'implémentation de la norme dans la synthèse.

ANALYSE DU STANDARD OCCURRENCE DE TAXON et de ses correspondances dans GeoNature :

analyse-occtax-synthese

Confrontation du MCD Synthèse au module OccTax :

On ne reporte pas :

id_digitiser : propre au module et existence non garantie selon les modules sources
meta_device_entry : propre au module et existence non garantie selon les modules sources
hour_min et hour_max : propre au module et existence non garantie selon les modules sources

Autres : Mise à plat des observateurs au format character : pour le nn on sépare par des virgules.

Avantage : Permet d’intégrer facilement des données externes où les observateurs sont en format texte. Cela évite aussi d’intégrer au préalable tous les observateurs dans le schéma utilisateurs avant de pouvoir créer les enregistrements dans la synthèse.
Inconvénients : complexifie les triggers depuis les schéma source et perf moins bonnes lorsque l’observateur est utilisé dans les filtres.

Pour le moment on met de côté tout ce qui est attribut additionnel.

Questions :

Que fait-on avec le unique_id_sinp_grp = id_releve dans la future norme SINP occurrence de taxon ?
Comme il y a un commentaire pour relevé et un pour occurrence, que faut-il faire dans la synthèse. Actuellement il n’y a qu’un commentaire en synthèse.
Le champ sensible de la nomenclature 17 d’occurrence de taxon est égale à oui (97) ou non (96). On peut déduire la sensibilité de la nomenclature 16. Si le cd_nomenclature est = à 0 (68) l’observation n’est pas sensible.
- Faut-il ajouter cette nomenclature à la synthèse comme les autres ?
- Faut-il ajouter cette information non sous forme de nomenclature mais sous forme de boolean ?
L’occurrence de taxon propose une date de détermination (facultatif). Est-ce qu’on ajoute ça à occtax et/ou à la synthèse.

Point de vigilance :

On a un id_nomenclature_determination_method et un determination_method_as_text. Dans la synthèse comme dans la norme occurrence de taxon on a un determination_method au format text champ libre. Le trigger de occtax devra récupérer les labels nomenclature et non les id et faire un check entre le id_nomenclature_determination_method et le determination_method_as_text pour retenir celui qui est rempli.
Il y a 3 tables pour une occurrence et donc 3 meta_create_date et 3 meta_update_date mais il n’y en a qu’un dans la synthese. Le trigger insert et surtout les triggers update et delete devrons gérer tous les cas de figure possible. Si le meta_update_date est changé dans une des 3 tables, il faut mettre à jour celui de la synthèse.

A propos de l’uuid_sinp :

Je retire le SET DEFAULT uuid_generate_v4() ? Risque de générer un uuid différent de celui de la source du module interne. Mieux vaut générer volontairement un uuid en synthèse pour des données qui le nécessiteraient.
Je retire aussi le NOT NULL car si des données externes sont intégrées, l’uuid_sinp devrait être NULL (sauf s’il est fourni) car ce n’est pas à nous de le produire.
Il faut mettre en place un mécanisme qui permet de distinguer les données sources produite par l’outil, des données non produites par l’outil (dont la production de l’uuid_sinp, la mise à jour, la validation, la suppression, etc. n’incombe pas à l’outil). Cette distinction peut avoir d’autres usages que la gestion de la production de l’uuid.

camillemonchicourt commented 6 years ago

MES RÉPONSES :

De manière générale, à terme on va plutôt baser les exports SINP Occurrences de taxons sur la Synthèse car c'est là qu'il y aura nos données agglomérées des différents protocoles. Du coup si il y a des données du standard dans les données OCCTAX mais qu'on ne les reporte pas dans la Synthèse, on ne les remontera pas au SINP.

OK pour les observateurs, je penche aussi pour les mettre en texte dans la synthèse.

Comme il y a un commentaire pour relevé et un pour occurrence, que faut-il faire dans la synthèse. Actuellement il n’y a qu’un commentaire en synthèse.

Dans la synthèse, il faut agglomérer le commentaire du relevé (si il existe) avec le commentaire du taxon.

On a un id_nomenclature_determination_method et un determination_method_as_text.

Je pense que ce n'est pas un bon choix au niveau de OccTax. Je suis pour virer le determination_method_as_text

camillemonchicourt commented 6 years ago

En plus du champs texte "observateurs", on a évoqué le fait d'avoir une table NN ou un champ array avec les ID_roles des observateurs car sinon on ne pourra pas utiliser le CRUVED de portée 1 dans le module Synthèse.

On a aussi parlé d'ajouter la dernière valeur de Validation à plat dans la Synthèse pour en disposer facilement (et permettre d'avoir des infos de validation dans la Synthèse sans les avoir dans la table transversale de Validation, pour des données externes par exemple ?)

TheoLechemia commented 6 years ago

Pour la portée CRUVED 1, il est toujours possible de faire sans table de correspondance. L'utilisateur connecté a un nom et prenom que l'on peut comparé au nom de l'observateur en texte... C'est beaucoup plus bancale par contre. Cependant un utilisateur connecté est forcément dans la table t_roles donc c'est un peu dommage de se priver de cet info. On pourrait imaginer un système mixte, où si on a l'id de l'observateur on le note dans une table de correspondance ou dans un champs de type array, et un champ observateur que l'on rempli systématiquement en texte. Le CRUVED de niveau 1 (assez rare quand même), compose avec ses deux infos. C'est pas idéal, c'est sur

camillemonchicourt commented 6 years ago

Oui si on stocke les id_roles, cela doit être optionnel, car dans la Synthèse, il y a pas mal d'observateurs qui ne seront pas listés dans t_roles. Si on parle là-dessus, je n'utiliserai que ce champs pour le CRUVED portée 1, je ne comparerai pas en plus avec le champs Observateurs texte.

gildeluermoz commented 6 years ago

On est clairement ici sur des choix qui vont fortement influencer les perfs. Identifier les données comprises dans la portée d'un user parmi 1,2,3,4,10 millions de données nécessite une bonne indexation de l'info. Clairement, on mode text, c'est même pas la peine d'y songer.

Comme l'observateur c'est du n-n, on a trois choix :

renoncer à la portée 1 pour les données qui auraient été importées sans id_role (s'en tenir à la porté 2 = "mon organisme")
mettre les id_role dans une table de correspondance
mettre les id_role dans un champ de type array.

Pour les 2 dernières options, je m'enquière de savoir si le sujet des conséquences de l'une ou l'autre des 2 options a déjà été traité sur le net. Sinon il faudra faire des tests.

camillemonchicourt commented 6 years ago

Oui clairement pour les données qui n'ont pas d'id_role, elles ne remonteront pas pour les utilisateurs ayant un CRUVED de portée 1. C'est pas un problème.

camillemonchicourt commented 6 years ago

Ça fait plaisir de fermer un tel ticket !

Le travail a été avancé et une première stable de la Synthèse est en place : https://github.com/PnX-SI/GeoNature/blob/develop/data/core/synthese.sql#L91-L151

Les différents points mentionnés dans ce ticket ont été traités, voici des compléments sur ce qui a été fait sur les points en suspens :

Pour le moment si la source ne fournit pas de unique_id_sinp, on n'en écrit pas.

Pour les nomenclatures, si elles ne pas sont renseignées lors de l'intégration de données dans la Synthèse, elles prennent la valeur par défaut définie dans la table gn_synthese.defaults_nomenclatures_value, grace à la fonction :

gn_synthese.get_default_nomenclature_value(myidtype character varying, myidorganism integer DEFAULT 0, myregne character varying(20) DEFAULT '0', mygroup2inpn character varying(255) DEFAULT '0')
RETURNS integer
--Function that return the default nomenclature id with wanteds nomenclature type, organism id, regne, group2_inpn
--Return -1 if nothing matche with given parameters

id_municipality et id_area ont été supprimés de la table Synthèse, car ils sont gérés dans cor_area_synthese (alimentée automatiquement par un trigger).
Idem pour les mailles et les unités géographiques
1 ligne dans la Synthèse = 1 dénombrement
cd_nom permissif et non obligatoire.
Pas de contrainte CHECK IF cd_nom IS NULL THEN nom_cite IS NOT NULL car c'est le champs nom_cite qui a été mis en NOT NULL
Pour les observateurs, on peut les renseigner en texte dans un champs observers ou avec leur id_role si il s'agit de données saisies dans GeoNature
Par contre determiner et validator sont uniquement en champs texte
id_digitiser est un integer, avec un id_role basé sur utilisateurs.t_roles (utile pour le CRUVED)
determination_method et sample_proof_number ont été intégrés
determination_method_as_text a été supprimé car on n'a plus ce champs texte dans Occtax qui a été remplacé par une nomenclature (liste)
On a un id_source et un id_dataset dans la Synthèse
Commentaire : On agglomère celui du relevé et celui de l'observation

Calcul de la sensibilité non intégré pour le moment, à traiter plus tard dans un ticket dédié : https://github.com/PnX-SI/GeoNature/issues/413

PnX-SI / GeoNature

MCD Synthese #207

Confrontation du MCD Synthèse au module OccTax :