[OccHab] Intégration standards SINP V2.0

[ch-cbna]

Version Develop

Depuis février 2022, le SINP a diffusé de nouveaux standards pour l'échange des données d'observations sur les habitats (V2.0).

Les modifications entre la version 1.0, qui est aujourd'hui le support d'OccHab, et la version 2.0 du standard sont consultables de la page 17 à la page 21.

J'ouvre la discussion pour connaître vos avis/besoins en ce qui concerne ces modifications :

• Renomme-t-on les tables centrales (Station--> Evènement, Habitat --> ObservationHabitat) ?
• Quels concepts facultatifs ajoute-t-on (LienEspeces, Site, Evaluation, LienHabitats, ValidationProducteur, ValidationRegionaleOuNationale) ?
• Quels attributs ajouter et/ou supprimer ?
• Quelles nomenclatures ajouter et/ou supprimer ?

[camillemonchicourt]

Merci pour ce travail. En effet la mise à jour du module Occhab pour le faire évoluer en lien avec la V2 du standard Occurrences d'habitats est un chantier à mener.

Dans le cadre de la convergence des standards français du SINP avec les standards internationaux (Darwin core), la notion d'événement a en effet été intégrée pour remplacer les concepts de stations (habitats) et de relevés (taxons).

Schématisé ici dans le document du standard v2 (https://inpn.mnhn.fr/docs-web/docs/download/399452) :

Mais cela pose en effet la question de l'appellation pour être cohérent avec les standards mais aussi compréhensible pour les utilisateurs.

Je dirai que la BDD doit respecter les termes du standard, mais que le concept d’événement est flou et abstrait et sera difficilement compréhensible par les utilisateurs qui vont saisir.

Cela renvoie aussi au fait que l'on utilise un standard technique d'échange de données, en tant que standard de structuration et de saisie de nos données.

Du coup, peut-être qu'il faut utiliser le terme d’événement dans la BDD, mais continuer à parler de station (et de relevé au niveau d'Occtax) au niveau des interfaces utilisateurs, des fichiers exportés...

L'inconvénient de cela est que cela va apporter des différences entre les vocabulaires dans la BDD et ceux des interfaces.

A réfléchir, discuter.

---

Pour les champs à ajouter/valider, il faut bien se caler sur cette nouvelle version du standard, sauf si certains champs posent question.

Il reste toujours à garder en tête que l'on utilise un standard d'échange en temps que standard de saisie et de structuration des données, ce qui peut amener quelques questions et/ou ajustements.

[ch-cbna]

Suite à un travail d'analyse du standard habitats v2, je propose ici une version d'OccHab v2, qui prend en compte ce nouveau standard :

Les concepts facultatifs Validation Producteur et Validation Regionale ou Nationale ne sont pas présents dans ma proposition d'OccHab v2, car je ne sais pas s'il faut les intégrer dans le schéma pr_occhab étant donné que la validation des données de la Synthèse se trouve dans le schéma gn_commons. Deux points importants sont à prendre en compte à ce sujet :

• La table t_validation actuelle ne dispose pas de tous les attributs obligatoires du concept ValidationRegionaleouNationale du standard habitats v2, il faudra prévoir de les ajouter.
• Le module Validation étant commun avec le module Synthèse, il faudra créer un module validation qui reprendra l'interface du module OccHab.

Je me questionne sur le concept LienHabitats. Il permet d'établir un lien entre plusieurs observations d'habitat, notamment un lien de correspondance typologique (valeur 1 dans la nomenclature TypeLienValue). Est-ce que ce mécanisme induit la duplication de chaque habitat par typologie ? Par exemple, la plupart des données habitats N2000 sont mises en correspondances avec les typologies EUNIS, Corine Biotopes, Cahiers d'habitat et HIC. Est-ce qu'il faudra intégrer chacune de ces données habitats 4 fois, une fois pour chaque typologie, et ainsi les relier entre elles avec typeLien = 1 ? Dans ce cas, ce sera la table cor_habitats qui établira ces liens.

Vous trouverez le détail de la mise en correspondance des tables d'OccHab (v1) avec le standard habitats v2 dans ce document.

Cette proposition est ouverte à discussion et modification. On pourrait par exemple rajouter l'attribut etatConservation pour les observations d'habitat, par rapport au besoin cité dans le ticket #1799 .

[camillemonchicourt]

OK merci pour ce travail de comparaison. Quelques remarques et questions :

• Si on garde ce vocabulaire et notamment valide de renommer "Stations" en "Événements", alors ça serait plutôt "t_evenements" (ou "t_evenements_station") et "t_observations_habitat"
• Pourquoi pas supprimer des champs, mais il faut bien en mesurer les conséquences
• Il peut aussi y avoir des champs spécifiques à GeoNature qui ne sont pas présents dans le standard du SINP. Il faut notamment garder en tête que l'on utilise un standard d'échange en tant que standard de saisie et gestion des données. Par exemple il faut garder "observers_txt" qui est nécessaire à GeoNature. On peut se poser la même question pour les altitudes et profondeurs qui peuvent être nécessaires à GeoNature, mais pas à l'agrégation nationale prévue par le standard. Et on a ces infos dans les relevés Occtax donc faire pareil pour être cohérent et homogène ?
• Pas certain qu'il faille ajouter un organisme au niveau de chaque observation. En tout cas on ne le fait pas dans Occtax où on saisie et stocke seulement des observateurs au niveau de chaque relevé, desquels on peut déduire leur organisme, mais surtout car on déduit les organismes d'un relevé à partir des organismes associés en tant qu'acteur au JDD associé au relevé. Faire pareil pour être cohérent et homogène ?
• Le fait d'avoir des "idOrigin" est cohérent et logique dans le standard qui est un standard d'échange et d'agrégation de données, mais pose plus de questions dans notre question où le module Occhab est essentiellement le module d'origine. A priori je ne le mettrai pas car l'idOrigin de l'objet est son ID dans GeoNature. Et on ne fait pas ça dans Occtax donc à voir pour la cohérence.
• "Site_name" et "Zone_type" sont à clarifier et à évaluer leur pertinence, car ils n'ont pas forcément de pertinence dans le cadre du module Occhab
• Je ne comprends pas bien "typo_name" vu qu'on peut déduire la typologie à partir du cd_hab. Redondant et donc risqué à mon avis.
• A clarifier et discuter aussi si on doit mettre en place le concept facultatif "LienEspeces" qui est traduit par l'ajout des champs "unique_id_sinp_grp". Celui-ci "Permet de faire le lien avec un regroupement d’observations de taxons (par exemple un relevé d'espèces), tel qu’identifié lors de l’échange de données via le standard Occurrences de taxon." Mais cela questionne le positionnement d'Occhab et son lien avec Occhab. Uniquement pouvoir renseigner un ID d'un relevé d'Occtax dans un champs me semble discutable. Pour quoi faire ? Dans quel contexte ? Quel usage ?
• Concernant la validation, clairement l'actuelle table gn_commons.t_validations est faite pour stocker les validations des occurrences de taxons. A voir si elle peut recevoir aussi celles des occurrences d'habitats ou si il faut une table dédiée à la validation des occurrences d'habitat
• A voir aussi comment et où on veut pouvoir valider des occurrences d'habitat. En tout cas, c'est à dé-corréler de la saisie d'un habitat, même si ça peut être fait dans le même module que celui de saisie, contrairement aux occurrences de taxons, où la saisie est faite dans Occtax, la recherche dans Synthèse et la validation dans le module dédié Validation. Pour Occhab, on peut envisager que le module regroupe les fonctionnalités de saisie, recherche, export et validation, mais c'est une question globale qui va au-delà de la question de standard
• Concernant les correspondances d'habitat, selon moi elles doivent être gérées au niveau de Habref et non pas au niveau de chaque occurrence d'habitat. Et clairement pas dupliquer un habitat pour ses différentes correspondances

[maximetoma]

Je suis en train de commencer à regarder pour mettre en forme un modèle pour la refonte d'OccTax par rapport à la très prochaine sortie du nouveau standard V3

Je remarque que la table des événements se veut commune au standard habitat avec la possibilité de faire un lien entre les habitats et les relevés phytosocio (ou taxonomiques) entre les 2 nouveaux standards

Ainsi, (la réflexion est va peut-être trop vite et trop loin mais) j'ai l'impression que la table "evenement" doit être décentrée des schemas pr_occtax et pr_occhab OU à contrario, rejoindre les deux schemas pour en former qu'un seul... mais est-ce profitable ? Quelle est votre avis là-dessus ?

Ci-dessous le modèle pour OccTax V3 (ou ObsTax V3)

[camillemonchicourt]

Oui, bonne question. Regrouper les relevés Occtax et les Stations Occhab ne serait pas anodin et pourrait apporter de la complexité. A voir ce qu'on y gagne et ce que ça impliquerait.