lpoaura / gn_vn2synthese Goto Github PK

Bonjour,
En tentant de faire tourner les scripts, ce que je n'ai pas encore réussi en totalité.
Je pense avoir trouvé plusieurs coquilles.

fct_c_get_or_insert_dataset_from_shortname

1 - nb param

Dans 02_metadata, la function prend 3 param alors que dans 09a_init_data_metadata. Il n'y en a que 2, ce qui cause une erreur.

function src_faune.fct_c_get_or_insert_dataset_from_shortname(text, text) does not exist
  Indice : No function matches the given name and argument types. You might need to add explicit type casts.
  Position : 15

2 - Nom function

dans 09a_init_data_metadata, la function appelée est fct_get_or_insert_dataset_from_shortname au lieu de fct_c_get_or_insert_dataset_from_shortname

SELECT
    src_lpodatas.fct_get_or_insert_dataset_from_shortname(
            gn_commons.get_default_parameter('visionature_default_acquisition_framework'),
            gn_commons.get_default_parameter('visionature_default_dataset'));

3 - Insert dans dataset

Il y a une coquille dans 02_metadata, mauvais appel d'une variable définie.

INSERT INTO
            gn_meta.t_datasets ( id_acquisition_framework
                               , dataset_name
                               , dataset_shortname
                               , dataset_desc
                               , marine_domain
                               , terrestrial_domain
                               , additional_data
                               , meta_create_date)
            VALUES
                ( src_lpodatas.fct_c_get_id_acquisition_framework_by_name(gn_commons.get_default_parameter(_default_acquisition_framework))
                , '[' || the_shortname || '] Jeu de données compléter'
                , the_shortname
                , 'A compléter'
                , FALSE
                , TRUE
                , jsonb_build_object('standard_name', the_shortname)
                , now())
            RETURNING id_dataset INTO the_id_dataset;

Correction possible pour être en cohérence avec 09a_init_data_metadata

select gn_commons.get_default_parameter(_default_acquisition_framework);
--devient
select gn_commons.get_default_parameter('visionature_default_acquisition_framework') ;

4 -

 SELECT
        coalesce(_shortname, gn_commons.get_default_parameter(_default_dataset))
        INTO the_shortname;

Même probleme que 3

select gn_commons.get_default_parameter(_default_dataset);
-- devient
select gn_commons.get_default_parameter('visionature_default_dataset');

Je voudrais utiliser ce module pour faune-bretagne, j'ai actuellement une vm avec Geonature et une autre vm avec le client_API_VN.
Cette architecture est-elle compatible avec ce module ?

Avec un territoire par défaut dans gn_commons.t_parameters

La recherche de cadres d'acquisition s'effectue depuis acquisition_framework_name. Plutôt utiliser une valeur du champ additional_data.

Lorsqu'un utilisateur change son statut d'association aux obs (utilisateur anonyme), la mise à jour n'est pas répercutée dans la table utilisateurs.t_roles.champs_addi.

Il est également nécessaire de mettre en place une routine (à réfléchir) pour rétroactivement mettre à jour les données de synthèse en conséquence (anonymisation/dés-anonymisation).

Rattachement des personnes morales, Quelques règles d'attribution des JDD/CA applicables en AuRA

• Lorsque la donnée a un code étude: On créée ou récupère le JDD/CA de la donnée d'après le code étude
• Lorsque la donnée n'a pas de code étude mais que l'observateur fait partie d'une personne morale (cf. tables observers <> entities), alors on créée ou récupère le JDD/CA générique de la personne morale.
• Lorsque la donnée n'a ni code étude, ni personne morale et que c'est une donnée une donnée d'Odonate en RA, alors elle intègre le CA/JDD de Sympetrum ( !!! Exception AuRA !!!)
• Sinon, on lui attribue sont CA générique par défaut.

👉 En utilisant les scripts SQL de la branche next pour la BDD GeoNature Pays de la Loire, j'ai repéré ce qui me semble être quelques coquilles (ou peut-être pas 🤷‍♀️) :

00_init_db.sql

Manque le nom du schéma src_lpodatas :

07_update_synthese_extended.sql

Il y a un gnadm qui traîne alors que partout ailleurs c'est geonatadmin :

08a_init_data_nomenclatures.sql

J'ai l'impression que ce bloc est un test ? Je me demandais s'il n'était pas nécessaire de le commenter :

il faudrait corriger par "à compléter"

Actuellement, la mise à jour des observateurs peut s'avérer problématique en cas de changement sur les comptes utilisateurs avec un possible conflit sur la contrainte d'unicité du champ email (cf. PnX-SI/UsersHub#122).

Pour l'heure et pour éviter de rentrer dans une usine à gaz face à la multitude des cas de figure (fusion de deux comptes, création d'un nouveau compte après changement de l'adresse mail de l'ancien compte, etc.), il sera réalisé un travail d'écriture de scripts pour gérer ces conflits à la main.

Actuellement, la caractérisation de la date de l'observation utilise la donnée du chemin json {date,@timestamp} dont la précision est le jour.

Pour obtenir la date et l'heure précise de l'observation, il faut utiliser le chemin {observers,0,timing,@timestamp}.

J'ai repris les scripts SQL de la branche next pour la BDD GeoNature Pays de la Loire. Je vois que la table utilisateurs.t_roles n'est pas peuplée, alors que les triggers et fonctions nécessaires sont bien présents. Dans la BDD ODF je remarque que c'est la même chose, je ne sais pas si c'est normal ?

En tout cas pour PACA ça fonctionne très bien mais impossible de trouver la différence entre les scripts...

Mettre en place un trigger sur species_json pour automatiser la mise en correspondance des taxons VisioNature avec TaxRef (table taxonomie.cor_c_vn_taxref).

Dans les cas ou un utilisateur a plusieurs comptes, l'interversion des email provoque des erreurs à l'insertion dans t_roles en raison de la contrainte d'unicité des emails.