Projet

Général

Profil

Evolution #235

Nom vernaculaire divergent selon Sicen et Serena, ou vide dans Sicen

Ajouté par Rolland PAILLAT il y a environ 7 ans. Mis à jour il y a presque 4 ans.

Statut:
Résolu
Priorité:
Normal
Assigné à:
Début:
18/04/2018
Echéance:
27/04/2018
% réalisé:

0%

Temps estimé:
1.00 h

Description

Plusieurs choses :
1- La saisie d'une obs dans Sicen par nom latin ne remplit pas automatiquement le nom vernaculaire, alors que l'inverse fonctionne bien.
2- La vue matérialisée commune faisant l'agrégation des deux bases de données, les noms vernaculaires renseignés sont différents. Cela pose un problème lors de l'exploitation carto sous Qgis, où une catégorisation des valeurs selon le nom vernaculaire fait apparaître par exemple "Crapaud commune" et "Crapaud commun (Le)", ou "grenouille agile" et "Grenouille agile".


Fichiers

Capture du 2018-04-18 11-37-08.png (128 ko) Capture du 2018-04-18 11-37-08.png Rolland PAILLAT, 18/04/2018 14:50
Capture du 2018-04-18 11-38-41.png (208 ko) Capture du 2018-04-18 11-38-41.png Rolland PAILLAT, 18/04/2018 14:50

Historique

#1

Mis à jour par Ludovic Lestrat il y a environ 7 ans

Question 1

Il faudrait que je fasse des tests avec des exemples précis pour voir si un mécanisme est défaillant.
Sur le plan conceptuel, il est possible qu'un nom latin n'est pas de nom vernaculaire, ce qui n'est pas vrai pour l'inverse. Mais je suppose que dans tes tests, tu as utilisé les noms latins qui était ressortis par le nom vernaculaire, donc normalement effectivement, çà aurait du marcher dans l'autre sens.

Question 2 :

  1. Première différence :
    - le nom vernaculaire dans SICEN est enregistré en base (quand il veut bien le faire) au moment de la création de la donnée. Il prends la valeur du nom vernaculaire présent dans la version de taxref disponible au moment de la création, il ne changera plus (même si taxref change).
    - dans Serena, il préfère enregistrer la référence au taxon dans la table d'observation et récupère donc le nom vernaculaire du taxon de la version actuellement disponible de taxref dans l'application.
  2. Deuxième différence : le référentiel taxref.
    - Si théoriquement, les deux outils se basent sur le même référentiel, on sait que Pierre Girard y apporte des modifications.
    - On a aussi un delta de passage d'une version de taxref à l'autre dans chaucn des outils.
    - Les versions de taxref change et, apparemment, le nom vernaculaire dans taxref change aussi.
  3. Troisième paramètre :
    La vue matérialisée prend comme nom vernaculaire celui de la table SICEN d'une part, et celui du référentiel Taxo de Serena d'autre part. Si ce champ n'est pas renseigné, et ce cas arrive comme tu le cites en premier point, il récupère dans la version actuelle de taxref le nom_vernaculaire disponible.

Plusieurs solutions se présentent :

- automatiser une actualisation des noms vernaculaires dans les tables de SICEN et Serena, ce qui fait que seul le nom vernaculaire de la version actuelle officielle (pas celle de Serena) de taxref ressortirait. Je n'aime pas trop cette solution car on risque aussi sur des données anciennes d'en supprimer la valeur initiale qui peut-être a un intérêt,
- faire vos analyses thématiques en vous basant sur les cd_noms et écrivant les noms dans les libellés "à la main",
- faire vos analyses thématiques avec des règles en mettant des critères flous, ex nom_venra ILIKE '%grenouille%agile%'.

#2

Mis à jour par Rolland PAILLAT il y a environ 7 ans

Ludovic Lestrat a écrit :

Question 1

Il faudrait que je fasse des tests avec des exemples précis pour voir si un mécanisme est défaillant.
Sur le plan conceptuel, il est possible qu'un nom latin n'est pas de nom vernaculaire, ce qui n'est pas vrai pour l'inverse. Mais je suppose que dans tes tests, tu as utilisé les noms latins qui était ressortis par le nom vernaculaire, donc normalement effectivement, çà aurait du marcher dans l'autre sens.

Test refait à l'instant avec la Fritillaire pintade "Fritillaria meleagris", qui a bien un nom vernaculaire associé. La complétion fonctionne depuis le nom verna vers nom latin, mais pas l'inverse.

Question 2 :

  1. Première différence :
    - le nom vernaculaire dans SICEN est enregistré en base (quand il veut bien le faire) au moment de la création de la donnée. Il prends la valeur du nom vernaculaire présent dans la version de taxref disponible au moment de la création, il ne changera plus (même si taxref change).
    - dans Serena, il préfère enregistrer la référence au taxon dans la table d'observation et récupère donc le nom vernaculaire du taxon de la version actuellement disponible de taxref dans l'application.
  2. Deuxième différence : le référentiel taxref.
    - Si théoriquement, les deux outils se basent sur le même référentiel, on sait que Pierre Girard y apporte des modifications.
    - On a aussi un delta de passage d'une version de taxref à l'autre dans chaucn des outils.
    - Les versions de taxref change et, apparemment, le nom vernaculaire dans taxref change aussi.
  3. Troisième paramètre :
    La vue matérialisée prend comme nom vernaculaire celui de la table SICEN d'une part, et celui du référentiel Taxo de Serena d'autre part. Si ce champ n'est pas renseigné, et ce cas arrive comme tu le cites en premier point, il récupère dans la version actuelle de taxref le nom_vernaculaire disponible.

Plusieurs solutions se présentent :

- automatiser une actualisation des noms vernaculaires dans les tables de SICEN et Serena, ce qui fait que seul le nom vernaculaire de la version actuelle officielle (pas celle de Serena) de taxref ressortirait. Je n'aime pas trop cette solution car on risque aussi sur des données anciennes d'en supprimer la valeur initiale qui peut-être a un intérêt,
- faire vos analyses thématiques en vous basant sur les cd_noms et écrivant les noms dans les libellés "à la main",
- faire vos analyses thématiques avec des règles en mettant des critères flous, ex nom_venra ILIKE '%grenouille%agile%'.

Y'aurait-il une quatrième solution ? garder les noms vernaculaires indiqués dans SICEN et Serena dans chacune des 2 bases, mais lors de la création de la vue matérialisée prendre directement celui dispo dans taxref. Comme ça on garde l'historique et on a quelque chose d'homogène quand même dans la vue matérialisée.

#3

Mis à jour par Ludovic Lestrat il y a environ 7 ans

  • Echéance mis à 27/04/2018
  • Assigné à mis à Ludovic Lestrat
  • Temps estimé mis à 1.00 h

Bien vu cette 4ème solution. Ca donnerait plutôt : prendre en premier le nom vernaculaire du taxref "officiel" INPN, et si nul, prendre celui de la donnée d'origine s'il existe. Ca limitera déjà le nombre de cas.
Merci pour la proposition

#4

Mis à jour par Ludovic Lestrat il y a presque 7 ans

  • Statut changé de Nouveau à Résolu

Si nom vernaculaire présent pour un cd_nom dans taxref, problème résolu.
sinon prend la valeur issue de la base source.

Le traitement des noms vernaculaires des sous-espèces à ce stade n'est pas envisageable.

#5

Mis à jour par Rolland PAILLAT il y a environ 4 ans

Rolland PAILLAT a écrit :

La saisie d'une obs dans Sicen par nom latin ne remplit pas automatiquement le nom vernaculaire, alors que l'inverse fonctionne bien.

Salut,

Le problème existe toujours. J'ai saisi la Renouée de Bohème via son nom latin dans Sicen : Reynoutria x bohemica. Le nom vernaculaire n'est pas complété automatiquement, et n'apparaît donc pas. Pour moi ce n'est pas un problème, mais quand d'autres collègues ont voulu chercher ma donnée de "Renouée de Bohème", ils n'ont rien trouvé car ils ont fait la recherche avec le nom vernaculaire.

#6

Mis à jour par Ludovic Lestrat il y a environ 4 ans

La question est ou tes collègues regardent-ils ?
S'ils regardent dans SICEN, ce n'est pas une bonne idée car du coup, ils ne verront pas les saisies effectuées sous Serena.
S'ils regardent dans les vues vum_faune et vum_flore (depuis Qgis ou redash), ils auront les noms vernaculaires car la solution 4 décrite plus haut s'applique.

Dans ma "grande bonté", j'ai tout de même forcé l'actualisation des noms vernaculaires de la table de SICEN, 3514 obs ont gagné un nom vernaculaire du coup. C'est du one shot, mais on pourra relancer la requête d'update si besoin (qui ne devrait pas être, cf ma première réponse).

A+

#7

Mis à jour par Rolland PAILLAT il y a presque 4 ans

Ludovic Lestrat a écrit :

La question est ou tes collègues regardent-ils ?
S'ils regardent dans SICEN, ce n'est pas une bonne idée car du coup, ils ne verront pas les saisies effectuées sous Serena.
S'ils regardent dans les vues vum_faune et vum_flore (depuis Qgis ou redash), ils auront les noms vernaculaires car la solution 4 décrite plus haut s'applique.

Dans ma "grande bonté", j'ai tout de même forcé l'actualisation des noms vernaculaires de la table de SICEN, 3514 obs ont gagné un nom vernaculaire du coup. C'est du one shot, mais on pourra relancer la requête d'update si besoin (qui ne devrait pas être, cf ma première réponse).

A+

Merci pour votre "grande bonté" mon seigneur, nous n'en sommes pas dignes ;-) Alors j'ai commencé un rapide sondage à l'oral au bureau : la plupart des collègues "demandent à Rolland" quand ils ont besoin de trouver une info sur une espèce. Et si Rolland n'est pas disponible, ils regardent éventuellement dans les PG. Ça fait au moins plaisir de se sentir utile :-) Manue sait utiliser Sicen mais pas les autres. Et je pense que seule Nolwenn sait utiliser les vues faune et flore/fonge depuis QGis.
Perso j'aimerai bien l'idée que les collègues soient un peu autonomes sur la consultation de données faune/flore, mais les outils sont trop complexes pour eux je pense. Mais au final la plupart préfèrent demander directement à moi plutôt que s'embêter...

#8

Mis à jour par Ludovic Lestrat il y a presque 4 ans

Merci Rolland pour le retour.

Ca laisse à penser que pour enrichir les pratiques, il serait bien de refaire une présentation rapide dans les antennes de l'usage de ces différents outils...

A+

#9

Mis à jour par Rolland PAILLAT il y a presque 4 ans

Enrichir les pratiques, c'est bien, changer les habitudes et facilités des gens, c'est bien aussi mais plus compliqué... Moi je suggérerais un mini-sondage, histoire de gagner du temps et savoir si la présentation rapide pourrait vraiment atteindre son but.

#10

Mis à jour par Ludovic Lestrat il y a presque 4 ans

Tu sais, j'ai obligation de moyen, pas de résultats ;)

Formats disponibles : Atom PDF