Mettre à jour vers Standard Occurrence de taxons V2

[camillemonchicourt]

On est actuellement sur la version 1.2.1.
La V2 est sortie il y a 6 mois.

Les évolutions ne sont pas majeures mais certaines intéressantes.

Les modifications sont listées au début du document : https://inpn.mnhn.fr/docs/standard/Occurrences_de_taxon_v2_0_FINALE_LONGUE.pdf

[camillemonchicourt]

Il semblerait que la version suivante soit sortie mi-janvier : http://standards-sinp.mnhn.fr/observations-et-suivis-de-taxons-v4-0/

Il s'agit de la V4.0, sans être passé par une V3.0. Et en étant renommé Standard et Dictionnaire de données "Observations et suivis de Taxon".

Pas certain que cela soit définitif car le document n'est pas référencé partout, par exemple ici : https://inpn.mnhn.fr/telechargement/standard-occurrence-taxon

[jbdesbas]

Merci pour le lien, la suppression des champs dsPublique, organismeGestionnaireDonnées, etc.. dans le standard va dans le sens de ce qui ce fait déjà dans GN : la gestion de ces questions au niveau des métadonnées : cool ! 👍

[camillemonchicourt]

A l'occasion de la refonte en cours du module Occtax (#758), on en profite pour passer de la version 1.2.1 à la version 2.0 du standard SINP Occurrences de taxons.

@TheoLechemia y travaille dans une branche dédiée : https://github.com/PnX-SI/GeoNature/tree/occtax-v2

• Ajout de la nomenclature "Comportement" (http://standards-sinp.mnhn.fr/nomenclature/110-comportement-des-occurrences-observees-2018-05-14/) / Voir Occtax : code atlas pour l'ornitho #566
• Ajout de l'habitat sur le relevé (cd_hab)
• Ajout de la méthode de regroupement (Description de la méthode ayant présidé au regroupement, de façon aussi succincte que possible : champ libre. Exemples : "Par strate", "Observations matinales".). Bof mais OK.
• Ajout de la nomenclature TypeRegroupement (Indique quel est le type du regroupement suivant la liste typeRegroupementValue. Liste non exhaustive : NSP (inconnu), Strat (Strate), Pass (Passage), Camp (Campagne), OP (opération), InvSta (Inventaire Stationnel)...) : OK mais pourrait être plutôt au JDD car lié au protocole.
• Ajout du Type d'info géographique (Indique le type d'information géographique suivant la nomenclature TypeInfoGeoValue. Exemple : "1" pour "Géoréférencement", "2" pour "Rattachement"). Non car pas adapté à Occtax où l'on ne peut pas faire de "rattachement". On pousse "Géoréférencement" comme valeur par défaut, et il est possible de modifier cette valeur par défaut si souhaité.
• Ajout de la profondeur (min et max). Non affiché par défaut.

Autre :

• methodeObservation devient techniqueObservation. Pour ça on doit virer la technique d'observation (qu'on avait ajouté au relevé) qui a vocation à basculer au protocole (JDD) basé sur Campanule. Grand débat déjà tourné dans tous les sens. Pour le moment, on la garde uniquement dans Occtax, renommé "Technique de collecte (Campanule)", masquée par défaut
• denombrementMin devient FACULTATIF : on les laisse obligatoire dans Occtax, mais facultatif dans Synthèse
• denombrementMax devient FACULTATIF : on les laisse obligatoire dans Occtax, mais facultatif dans Synthèse
• Les ajouts dans les nomenclatures intéressants, comme le stade de vie "Fruit"
• techniqueEchantillonnage/tailleEchantillon/uniteTailleEchantillon/effortEchantillonnage > Non car lié au protocole et à campanule. Ajouter cela apportait de la confusion quant à la vocation d'Occtax de faire de l'observation occasionnelle
• nomLieu : OK, masqué par défaut
• séparation entre les dates et les heures. C'est le cas dans Occtax mais pas dans la synthèse. A uniformiser (plus tard). En lien avec ce ticket : bug dans la synthese, la recherche pour une date ne donne pas les relevés avec un horaire  #778
• version de taxref. C'est un paramètre global à GN (gn_commons.t_parameters). Est-ce qu'il faut conserver la version de Taxref de la saisie de l'observation dans la mesure ou on ne garde pas le cd_nom d'origine quand on fait des migration Taxref ? Si je me souviens bien, ils ont proposé de virer version_taxref du standard car dans le standard le champs cd_nom correspond à un cd_nom_cité, que l'on ne modifie jamais. Pour nous c'est plutôt un cd_nom_calculé qui peut évoluer au gré des évolutions de Taxref. On a évoqué de garder notre cd_nom (modifiable) qui fait référence et d'ajouter un cd_nom_cité informatif, voir A l'import : ajout et calcul des champs de gestion cdNomCalcule et cdRefCalcule sur les données gn_module_import#115 (comment). Dans tous les cas, avec ou sans l'ajout de ce champs, ça me va de virer ce champs version_taxref car je vois pas trop l'intérêt ni l'usage. OK, on vire le champs de la synthèse. C'est plutôt lié à la version de Taxref utilisée pour un export.

A noter :

Il faut dissocier la structuration des données d'Occtax de ceux de la synthèse. Occtax, n'a effectivement pas vocation à permettre de saisir tout et n'importe quoi et doit se limiter aux données de type "contact aléatoire". Par contre la synthèse qui a une vocation agglomérative devrait peut être être plus complète avec le lieu dit, la précision geo, ...

Tableau de suivi de l'implémentation du standard dans GeoNature : https://github.com/PnX-SI/GeoNature/blob/occtax-v2/docs/implementation_gn_standard_occtax2.0.ods

[gildeluermoz]

De mémoire il y a des nomenclatures à mettre à jour. Notamment toutes les nomenclatures concernant les stades de végétation.
Et très probablement d'autres... Forza !

[camillemonchicourt]

Oui il y en a quelques unes.
Malheureusement les stades de végétation n'ont pas encore été intégrés.
Les ajouts de nomenclature entre la 1.2.1 et la 2.0 :

Ajouts d’éléments dans des nomenclatures :

DEEFloutageValue :

• NSP

ObservationTechniqueValue (anciennement ObservationMethodeValue) :

• Contact olfactif
• Empreintes et fèces

OccurrenceComportementValue :

• Toutes les valeurs

OccurrenceStadeDeVieValue :

• Fruit

OccurrenceStatutBiologique :

• Végétatif

TypeAttributValue :

• NSP

TypeValValue :

• NSP

[samuelpriou]

Une belle avancée en attendant avec impatiente les nomenclatures concernant les stades de végétation !
Merci

[camillemonchicourt]

Le champs "Niveau de précision de la diffusion" (diffusion_level) était présent jusqu'à présent dans Occtax.

Pour les données sensibles, ce champs est calculé automatiquement dans la Synthèse, en fonction de la valeur du champs calculé "Niveau de sensibilité".

Cependant, pour les données privées non sensibles, certains observateurs souhaitent pouvoir définir un niveau de diffusion dégradé ou nul pour certaines observations.
Du coup il parait nécessaire de garder le champs diffusion_level dans Occtax, alimentant le champs correspondant dans la Synthèse dans le trigger Occtax >> Synthèse.

Le standard Occurrences de taxon du SINP indique :

diffusionNiveauPrecision : NiveauPrecisionValue
Alias : difNivPrec
Multiplicité : [0..1]
Niveau maximal de précision de la diffusion souhaitée par le producteur vers le grand public. Ne concerne que les DEE non sensibles (i.e. données dont le niveau de sensibilité est de 0). Cet attribut indique si le producteur souhaite que sa DEE non sensible soit diffusée comme toutes les autres, à la commune ou à la maille, ou de façon précise.
Règle : Il ne peut être utilisé pour diffuser moins précisément des données que dans le cas de données dont au moins une, au sein d'un regroupement, est sensible suivant la définition du GT sensible. Si aucune donnée n'est sensible, alors le niveau maximal de précision de diffusion sera celui par défaut.
Cet attribut est FACULTATIF.

La limite de cela est que :

• la fonction de calcul automatique de la sensibilité dans la Synthèse pourrait écrasé ce qui a été défini manuellement dans Occtax
• les calculs automatiques de niveau de diffusion basé sur le niveau de sensibilité sont stockés dans la Synthèse, mais pas répercuté dans Occtax, donc il peut y avoir une divergence des informations entre le niveau de diffusion dans Occtax et dans la Synthèse pour une même observation

Champs remis dans les tables d'Occtax, mais non saisissable dans le formulaire (#1059)

[camillemonchicourt]

Certains utilisent l'actuel champs "Technique d'observation" qu'on avait rajouté hors-standard, on propose de ne pas le supprimer brutalement.

Voila donc ce qui a été fait :

• Dans Occtax, renommer le champs "Méthode d'observation" en "Technique d'observation", basé sur l'actuelle nomenclature de "Méthode d'observation"
• Garder l'actuel champs "Technique d'observation" mais le cacher par défaut et le renommer "Technique de collecte Campanule" (ou du genre), pour ne pas perdre les données, toujours permettre sa saisie dans Occtax et son usage dans Occtax et se le garder en attendant que son positionnement soit clarifié avec Campanule
• Supprimer l'actuel champs "Technique d'observation" de la Synthèse, et y renommer le champs "Methode d'observation" en "Technique d'observation" pour limiter les risques de confusion au niveau de la synthèse, des exports Synthèse etc...

Le champs n'est donc gardé que dans Occtax pour ne pas perdre cette possibilité pour ceux qui l’utilisent déjà.

---

Pour la version de Taxref, on prévoit de supprimer le champs de la Synthèse, mais garder la valeur dans t_parameters, qui permet de savoir dans quelle version est un GeoNature et éventuellement de l'utiliser pour les exports.
Quand on met à jour Taxref, on le modifie pour les éventuelles données où on a mis à jour le cd_nom (après remplacement, split ou merge d'un cd_nom) et ça serait galère, donc potentiellement faux.

Cela reste à faire.

[camillemonchicourt]

Réalisé dans la 2.5.0. Reste le champs version_taxref à supprimer et quelques champs à discuter.