Statuts de validation

[xavyeah39]

Je m'interroge sur la transcription des statuts de validation dans l'interface du module de validation des observations qui sont actuellement formulés comme cela :

Correspondances avec les statuts (cf. models.py):

"---" ==> NOT_VALIDATED (valeur par défaut)
"L'identification est difficile, besoin d'un autre avis" ==> INVALID
"L'espèce observée n'est pas dans la liste des espèces de l'enquête" ==> NON_VALIDATABLE
"Les photos correspondent à des espèces différentes, l'observateur doit créer une nouvelle observation" ==> NON_VALIDATABLE

Je trouve que ces correspondances intitulés/statuts peuvent être trompeuses.

J'aurais par exemple tendance à vouloir associer NOT_VALIDATABLE à "L'identification est difficile, besoin d'un autre avis" (sous entendu non validable "en l'état")

Pour "L'espèce observée n'est pas dans la liste des espèces de l'enquête" : Comment peut-on saisir une espèce qui n'est pas dans "la liste des espèces de l'enquête" sur un programme ? Ne veut-on pas plutôt dire "L'espèce identifiée sur vos photos ne semble pas correspondre à celle selectionnée" ? Dans ce cas le statut ne serait pas plutôt INVALID ?

Pour "Les photos correspondent à des espèces différentes, l'observateur doit créer une nouvelle observation", le bon statut ne serait pas plutôt INVALID là aussi ? (dans la mesure où on demande de créer une nouvelle obs)

On pourrait aussi ajouter "La localisation ou l'identification de l'espèce semble incorrecte" ==> INVALID ?

Je ne pas expert en validation et ne maîtrise pas tout l'historique mais mes collègues on un peu de mal à s'y retrouver et me demande une petite clarification sémantique :)

Cela dit, il n'est pas évident de prévoir tout les cas de figures de validité/invalidité selon les programme et les contextes.
Peut-être envisager de permettre la personnalisation de la transcription des statuts et des messages envoyées aux observateurs ?

A minima on pourrait préciser à la fin des intitulés le statut de validation correspondant ?

Merci de vos retours !

Version

1.1.0

[camillemonchicourt]

Oui, on en avait discuté sur #359
J'aurai préféré se caler sur les statuts de validation du SINP pour être standard et homogène.

[hypsug0]

Merci @xavyeah39 pour ce retour,

En effet, cela mérite sans doute des éclaircissements et des ajustements. Les intitulés et codes de cette première version sont basés sur les besoins de la SHF pour leur programme "un dragon dans mon jardin" qui a financé ce développement.

j'avais en effet envisagé de permettre la personnalisation de ces statuts et messages ultérieurement.

Je pense aussi qu'il y a un quiproquos sur l'objectif de cet outil. Il a avant tout été construit pour permettre la correction des observations par un réseau d'identificateurs tout en informant automatiquement les observateurs des retours des identificateurs. Il n'a aucunement vocation à remplacer les fonctionnalités du module de validation de GeoNature.

[xavyeah39]

Merci @hypsug0 pour ces précisions.

Nous avons voulu tester cette nouvelle fonctionnalité de validation avec les PNR du Pilat, Vercors, Bauges et Livradois-Forez et faire un petit retour mais effectivement le cas d'usage de cette dernière ne répond pas tout à fait au besoin que nous cherchons à satisfaire :
Permettre aux chargés de missions référents de valider simplement les données saisies dans GNC pour qu'elles intègrent la synthèse de GeoNature et poursuivre leur route dans la transmission des données au SINP etc.

Jusqu'ici, nous n'utilisions pas le module de validation de GN car on ne fait pas de validation des données saisies en interne : peu de données, peu ou pas de spécialistes en interne, production souvent externalisée à des stuctures spécialisées lors d'étude etc... et surtout pas de temps agents fléché pour faire de la validation.

Nous l'envisageons donc essentiellement pour valider ponctuellement les données "grand public" en provenance de GNC mais cela peut effectivement se traiter par ailleurs avec le module de validation de GN qui est davantage fait pour ça !