Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Synthese, colorer les données invalides #968

Closed
Amegilla opened this issue Jul 8, 2020 · 14 comments
Closed

Synthese, colorer les données invalides #968

Amegilla opened this issue Jul 8, 2020 · 14 comments

Comments

@Amegilla
Copy link
Contributor

Amegilla commented Jul 8, 2020

Bonjour,

Ce serait intéressant (pour ne pas dire indispensable) que les données invalides ne s'affichent pas comme les autres dans la synthese. Elles pourraient ressortir avec une couleur différente par exemple.
En effet c'est assez trompeur pour un naturaliste de regarder la carte de la synthese sans cette information visible.
On peut aller plus loin en réfléchissant aux données douteuses etc...

Vous en penser quoi ?

@jbdesbas
Copy link
Contributor

Oui, idem pour les absence d'observation (StatutObs = No).
Peut-être même envisager de ne pas restituer par défaut ces obs dans la synthèse ?

Perso, pour mon usage quotidien j'ai crée un vue gn_synthese.synthese_usable qui filtre les invalides, douteux et non-observés. (pour éviter les mauvaises surprises)

@Amegilla
Copy link
Contributor Author

En fait pour toutes les restitutions cartographiques il faudrait systématiquement un code couleur pour l'information sur le statut de validation de la donnée et le statut de l'observation (Présent/Non observé). Avec une petite icône dans un coin de la carte qui s'étend pour afficher la légende quand on passe la souris dessus.

@DonovanMaillard
Copy link
Contributor

A mon avis ça ne doit pas passer par un code couleur ou un affichage en icone comme ca sur la synthèse. La synthèse sert a dire à quel endroit sont dispo des donnees mais si on met des légendes des couleurs et des icônes ca sera illisible (et niveau performances faudra récupérer et croiser plusieurs infos).

Le travail d'analyse doit être fait par l'utilisateur après coup. Par contre il serait intéressant je oense de :

  • mettre en avant dans la partie requête ces deux critères de validité et de presence/absence
  • rendre parametrable une requête "par defaut" sur ces deux informations

Par exemple par défaut sur mon instance je choisis d'afficher uniquement les donnees de présence valides ou en attente. Une information lindique, et xest clairement pré-rempli dans l'onglet requete pour que ca soit ajustable par l'utilisateur et totalement lisible

@Amegilla
Copy link
Contributor Author

Je comprends ton point de vue, et en effet avoir des cases à cocher/décocher en haut du formulaire sur ces critères éviterait des confusions. Cependant cela veut dire que si l'on veut afficher les données de présence et d'absence en même temps (ce qui est souvent plus intéressant que de les visualiser séparément) il ne sera pas possible de les distinguer.

@DonovanMaillard
Copy link
Contributor

De mon point de vue, la synthèse est là pour requêter et restituer les données qu'on lui demande et ça ne me choque pas que son rôle s'arrête là.

Je pense pas qu'il faille attendre de la synthèse qu'elle nous fasse une carte qui synthétise des informations sur mesure, avec des représentations diverses.

L'essentiel à mon avis, c'est que l'utilisateur soit informé de ce que la synthèse lui retourne comme données. Si par défaut on paramètre l'instance pour qu'elle n'affiche que les données de présence il doit le savoir, ensuite si lui demande en plus les données d'absence, c'est une info à analyser dans un second temps.

Ce qui me pose question dans l'approche c'est que tout le monde a des besoins d'analyse différent (chez nous les stades par exemple sont importants) et on ne pourra pas demander à la synthèse de tout représenter, colorer, légender etc.

@Amegilla
Copy link
Contributor Author

Oui mais le statut de validation et la présence/non observation n'est pas spécifique au groupe taxo.

@camillemonchicourt
Copy link
Member

Oui il faut éviter que GeoNature devienne un SIG.
Dans tous les cas, il faudrait aborder cela de manière générique car les statuts et nomenclatures peuvent être variables d'une instance à une autre. Donc éviter les comportements spécifiques.

@lepontois
Copy link

A minima, il serait bien que les filtres sur le statut d'observation (présence-absence) et sur la note de validation soient directement affichés sans avoir à passer par les filtres avancés et qu'il soit possible d'y choisir plusieurs valeurs (ex : extraire les données de présence dont les observations sont notées "certaine-très probable" ou "probable")

@jbrieuclp
Copy link
Contributor

Je relance cette issue pour proposer l'ajout de l'icone de l'état de validation dans le tableau de la synthèse (comme dans le tableau du module de validation). Ajouter l'icone ne va pas prendre beaucoup de place dans ce tableau, ajoute une vrai info importante qui se lit super vite et il ne vient pas interférer dans la restitution carto.

@camillemonchicourt
Copy link
Member

A rendre ça générique alors et voir si ça alourdit pas la récupération des données.
Voir si c'est paramétrable, à priori la liste des infos renvoyées est basée sur une vue et les colonnes affichées sont paramétrables.

Par exemple, dans notre cas, on n'a pas de validation des données, du coup on ne souhaite pas ajouter cette info ou un picto dans la liste des occurrences de la Synthèse.

@DonovanMaillard
Copy link
Contributor

DonovanMaillard commented Feb 1, 2021

Personnellement, je resterais plutôt sur l'idée que la synthèse ne fait que synthétiser et permettre le requêtage des données, sans chercher à tout représenter (validité, sensibilité, présence/absence etc).

Je serais davantage dans l'idée d'avoir un critère de requête qui filtre les données "Certaines" " probables" (configurable?) activé par défaut dans le panneau de recherche par exemple. Par ailleurs, ce mécanisme pourrait être fait de manière générique pour que tout administrateur puisse appliquer sur son instance des "filtres par défaut" selon ses thématiques et ses particularités, sans mettre en dur un critère plutôt qu'un autre (on ne fait pas non plus de validation en interne par exemple).

@Amegilla
Copy link
Contributor Author

Amegilla commented Feb 2, 2021

D'un point de vue naturaliste c'est dommage de ne pas pouvoir afficher toutes les données d'une espèce et voir les points valides et les invalidés car les deux sont source d'information et cela perds son intérêt si on l'on ne peut pas les afficher simultanément. Dans tout les cas le besoin d'un mécanisme pour clarifier l'utilisation de la synthese est nécessaire.

@DonovanMaillard
Copy link
Contributor

DonovanMaillard commented Feb 2, 2021

afficher toutes les données d'une espèce et voir les points valides et les invalidés car les deux sont source d'information et cela perds son intérêt si on l'on ne peut pas les afficher simultanément.

En effet, on n'est donc plus dans de la simple restitution/requête/export des données brutes (rôle aujourd'hui assuré par la synthèse), mais dans une interprétation/analyse des données. C'est quelque chose d'intéressant au niveau naturaliste, mais ça aurait sans doute plus sa place dans un dashboard par exemple, qui pourrait intégrer une "fiche taxon" avec une carte des données valides/invalides, une phénologie, un graph d'altitude qui est calculé dans les profils etc par exemple. En allant dans un module effectivement dédié à l'interprétation des données on pourrait du coup aller plus loin dans le rendu.

@camillemonchicourt
Copy link
Member

Dans la 2.12 a été implémentée la possibilité de définir des filtres activés par défaut dans la Synthèse avec l'exemple d'un filtre sur le statut d'observation et le niveau de validation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants