Open ch-cbna opened 1 year ago
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.
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 :
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.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 .
OK merci pour ce travail de comparaison. Quelques remarques et questions :
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'habitatJe 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)
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.
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 :