ref_geo - bib_type local / Dépendance schémas référentiels

[camillemonchicourt]

Actuellement on a les types dans ref_geo.bib_areas_types, mais on a commencé à migrer ça dans les nomenclatures.

Mais ça complexifie et créé des dépendances fortes entre schémas.

Plutôt garder les types locaux, plus simple et plus lisible.

[gildeluermoz]

pourquoi particulièrement ici et pas ailleurs ?

[camillemonchicourt]

Car du coup pour créer ref_geo, il faut ref_nomenclatures qui lui-même dépend de taxonomie.
Et nomenclatures dépend aussi du schéma utilisateurs (pour les valeurs par défaut par organisme).
Et ça créé aussi une dépendance avec public.fct_trg_meta_dates_change(). J'avais juste besoin du ref_geo dans notre serveur Lizmap et du coup ça a fait installer beaucoup d'autres choses non utilisées.

[camillemonchicourt]

On en a rediscuté avec Amandine.
Créer de la dépendance entre une BDD métier comme GeoNature et les nomenclatures est logique et apporte beaucoup à la BDD métier.
Par contre pour un référentiel comme REF_GEO ou TAXONOMIE créer de la dépendance avec REF_NOMENCLATURES est plutôt une contrainte.
D'ailleurs les typologies de la taxonomie (rangs, groupes...) sont gérées dans TAXONOMIE et pas dans REF_NOMENCLATURES, ce qui est une bonne chose.

Du coup, il nous semble important de faire pareil pour REF_GEO et de ne pas le rendre dépendant de REF_NOMENCLATURES. Cela apporte des contraintes mais pas d'avantages.

[gildeluermoz]

J'ai supprimé le lien qu'il y avait avec les nomenclatures pour rendre moins dépendant le ref_geo. Il permettait de répondre à un besoin de normalisation sinp. En effet, il correspondait à la nomenclature 22 du SINP sur les types d''espaces naturel (ZNIEFF, AB, PNR, PN, coeur de PNE, RNN, RNR, etc...). Peut-être faut-il réintroduire dans bib_areas_types, les éléments liés au SINP.

Une nouvelle fois la logique des sous-modules devant être totalement indépendant entre en conflit avec la logique de factorisation et d'harmonisation des pratiques.
On a besoin de fixer des règles et des priorités :

• harmoniser les pratiques et les logiques dans le MCD
• factoriser le code (les composants de formulaires s'appuient sur les nomenclatures)
• faire des référentiels indépendants du reste du modèle.

Dans quel ordre on aborde les complexités existantes et à venir ?

[camillemonchicourt]

Ah OK, c'etait donc la raison !
En effet garder une possibilité de lien pour mentionner qu'un type_area correspond à une nomenclature SINP peut être une bonne chose, tout en etant moins contraignant.

[gildeluermoz]

ajoutons
Nomenclatures intègre les nomenclatures SINP de l'INPN.
L'INPN produit aussi le référentiel taxonomie et un référentiel géo national.
Il est donc logique qu'il y ait un lien fort entre ces 3 référentiels. Soit on l'ignore et on éclate les nomenclatures dans les référentiels, soit on considère que nomenclatures est un référentiel de plus bas niveau et qu'il est un préalable à l'usage (et donc l'installation) des autres.
Donc

• TAXONOMIE et REF_GEO dépend de REF_NOMENCLATURES
• REF_NOMENCLATURES dépend de UTILISATEURS
• GEONATURE a besoin de ces 4 référentiels.

Ce qui donnerait dans l'ordre de dépendances et donc d'installations :

• UTILISATEURS <-- REF_NOMENCLATURES <-- (TAXONOMIE et/ou REF_GEO) <-- le reste de GEONATURE.

Si on respecte ça :

• il ne faut pas utiliser REF_NOMENCLATURES dans UTILISATEURS.
• il faut déplacer ref_nomenclatures.cor_taxref_sensitivity et ref_nomenclatures.cor_taxref_nomenclature dans TAXONOMIE

[TheoLechemia]

Cette option me parait être la bonne oui

[gildeluermoz]

Comme principe, je dirais aussi que tout ce qui est de plus haut niveau ne doit pas figurer dans le référentiel de plus bas niveau.
Ce qui donne par ex :

• cor_taxref_sensitivity et cor_taxref_nomenclature vont dans TAXONOMIE
• ref_nomenclatures.defaults_nomenclatures_value traite des nomenclatures par défaut de GEONATURE il faut donc le mettre dans gn_commons (comme chaque module à sa table defaults_nomenclatures_value).
  • Au passage on règle la dépendance entre REF_NOMENCLATURES et UTILISATEURS (car c'est dans defaults_nomenclatures_value qu'il y a le champ id_organism)
  • Et pourquoi pas remettre le champ id_module dans gn_commons.defaults_nomenclatures_value et tout centraliser. On facilite le back-office.
• l_geo_unities étant un besoin GEONATURE, il faut le mettre dans gn_synthese et non dans REF_GEO

Si on passe ref_nomenclatures.defaults_nomenclatures_value dans gn_commons
on aurait plus que 2 niveaux
1 (UTILISATEURS ET REF_NOMENCLATURES) <-- 2 (TAXONOMIE et/ou REF_GEO) <-- le reste de GEONATURE.
UTILISATEURS et REF_NOMENCLATURES sont totalement indépendants et constituent le plus bas niveau. Ensuite on peut ou non installer TAXONOMIE et/ou REF_GEO indépendamment l'un de l'autre mais ces 2 là s'appuient sur REF_NOMENCLATURES. Dans cette logique on pourrait pourquoi pas passer toutes les bib de taxref dans nomenclature (c'est pas urgent !).

Tout cela veut dire qu'on assume que REF_NOMENCLATURES est carrément central. Ce qui est logique car :

• les nomenclatures remplacent les "bib" et on s'en sert partout.
• Théo a basé ses composants de formulaire sur les id_type de ref_nomenclatures.bib_nomenclatures_types

En allant plus loin
REF_NOMENCLATURES pourrait se placer en tout premier, avant UTILISATEURS et constituer une brique de base pour tout le SI (Amandine fait déjà un peu ça). Ceci correspond aussi à son besoin qui a conduit à la discussion sur les liens a établir entre applications et nomenclatures. Une utilisateurs.cor_application_nomenclature remplacerait alors la ref_nomenclatures.cor_application_nomenclature.

[camillemonchicourt]

Oui, à première vue, ça me semble le mieux à faire par rapport aux éléments discutés ces derniers temps et les problèmes de dépendance rencontrées. Merci pour cette analyse.

A voir le retour d'@amandine-sahl sur le sujet.

[camillemonchicourt]

Au final, si on ne veut pas de dépendances entre les référentiels, la solution est peut-être une troisième option qui est de mettre les tables de correspondance entre les référentiels au niveau des applications métiers où on les utilise.

Ce qui amènerait à mettre cor_taxref_nomenclature et cor_taxref_sensitivity dans gn_commons.

[gildeluermoz]

Cette proposition de Théo sur le principe des référentiels qui sont bien indépendants et qui ne sont que des référentiels me plait bien.
Tous les liens à faire entre référentiels les rendent dépendants les uns des autres et potentiellement de manière croisée. Ce choix veut dire pas de table cor_ref1_ref2 mais aussi pas de FK entre référentiels.

Le seul inconvénient de sortir les tables contenant ces liens et de les mettre dans un schéma comme gn_commons est qu'il faudra potentiellement dupliquer ces liens si on en a besoin dans une autre appli /base. Mais ça me semble moins impactant que de créer des dépendances entre référentiels.
Je vote donc plutôt pour.

Et si on va jusqu'au bout, on fait un schéma refs_relations dans lequel on met les relations entre référentiels. Mais franchement c'est pas très lisibles et je préfère gn_commons.

[camillemonchicourt]

Ça veut aussi dire que si un jour on veut faire une interface pour gérer ces relations, on ne peut pas les intégrer dans l'outil de gestion du référentiel.
Par exemple si on veut gérer en interface les relations entre taxonomie et référentiel, on ne peut pas le faire dans TaxHub mais c'est à faire dans GeoNature.

Bon c'est d'ailleurs ce que l'on fait déjà dans l'Admin de GeoNature mais c'est peut-être du au fait que le module Nomenclature n'a pas (encore ?) d'interface dédiée.

[gildeluermoz]

C'est le prix de l'indépendance 😎
Inversement si tu fais un outil pour gérer les nomenclatures, et que tu y mets les liens avec taxonomie, tu devras installer le schéma taxonomie pour que ton outil fonctionne. Sauf à mettre un paramètre du genre 'withtaxo'
Si c'est geonature qui utilise le lien entre les deux c'est logique que ce soit dans l'admin geonature.
Dans l'admin de tes nomenclatures tu ne gères que des types et des nomenclatures.

[camillemonchicourt]

Oui ça me va, mais je soulignais juste ce point qui est à prendre en compte et garder en tête.

[camillemonchicourt]

Sujet à approfondir tranquillement avant de revoir le fonctionnement actuel.

On se garde ça pour plus tard.