You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Lorsqu’on filtre sur 2 types de zones géographiques à la fois dans les modules Synthèse ou Validation, aucune donnée n’est renvoyée (No data to display) alors qu’il existe des données.
Comportement attendu
Renvoyer des observations, mais selon quel fonctionnement ? :
Solution 1 :
On autorise l’utilisation d’un seul type de filtre géographique à la fois. Donc garder le fonctionnement actuel mais améliorer le frontend, soit en mettant les autres filtres disable si un est déjà sélectionné, soit un tooltip pour informer l’utilisateur – et enlever « no data to display » parce que la cause n’est pas claire pour l’utilisateur.
avantage : on ne touche rien en backend
inconvénient : finalement peu d’intérêt d’avoir plusieurs types de filtres géo ?
Solution 2 :
Pouvoir sélectionner plusieurs types de filtres géographiques à la fois, et tous les critères doivent être vrais ("ET"). Dans l’exemple ci-dessous, cela reviendrait donc à obtenir seulement les observations à Gap, donc l’utilisation de ces 2 filtres n’a pas tellement d’intérêt ici. Mais si on sélectionnait un département ET un PNR, par exemple Isère et PN des Ecrins, on obtiendrait seulement les observations du Parc situées en Isère. Est-ce que ce genre d’utilisation peut avoir une utilité métier ?
avantage : fonctionnalité en plus (utile métier?)
inconvénient : modification des filtres en backend
Solution 3 :
Pouvoir sélectionner plusieurs types de filtres géographiques à la fois, et au moins 1 doit être vrai ("OU"). Dans l’exemple ci-dessous, cela reviendrait donc à obtenir toutes les observations des Hautes-Alpes, donc dans ce cas l’utilisation de ces 2 filtres n’a pas tellement d’intérêt. Mais si on sélectionne des zones qui ne se recouvrent pas, ou partiellement, on peut obtenir une sélection des observations selon une couverture assez fine du territoire.
avantage : pas de modification importante des filtres en backend, grosso modo insérer une liste d’id de zones à la place d’un seul id dans la requête.
inconvénient : utile ?
Solution 4 :
Donner la possibilité à l’utilisateur de choisir le mode de filtrage ("ET" ou "OU") dans l’interface pour les différents types de filtres géographiques.
avantage :
Possibilité de sélectionner les données très finement selon leur localisation
inconvénients :
Complexifie le système de filtres en backend (plus de dev)
Complexifie l’UX
Manque d’homogénéité : car pourquoi ne pas le faire pour d’autres types de filtres (non géographiques) ?
Comment reproduire
The text was updated successfully, but these errors were encountered:
Pour la solution 3 ça pourrait être ajouter un PN + une ville n'étant pas dedans par exemple. Donc un filtre OU pourrait être utile.
Mais tous les filtres de la synthèse sont en ET si je ne dis pas de bêtise donc à des fin de cohérence les filtres géographiques doivent être en ET donc à Gap et dans les Hautes-Alpes. Ce qui reviendrait à ne pas autoriser plusieurs filtres géographiques...
Oui on en avait discuté pour les filtres géographiques au niveau des métadonnées.
C'est vrai que pour les filtres géographiques, un filtre "OU" semble plus pertinent.
Mais comme tous les filtres de la Synthèse fonctionnent en "ET", je resterai plutôt en "ET" pour la cohérence.
Version
Description du bug
Lorsqu’on filtre sur 2 types de zones géographiques à la fois dans les modules Synthèse ou Validation, aucune donnée n’est renvoyée (No data to display) alors qu’il existe des données.
Comportement attendu
Renvoyer des observations, mais selon quel fonctionnement ? :
Solution 1 :
On autorise l’utilisation d’un seul type de filtre géographique à la fois. Donc garder le fonctionnement actuel mais améliorer le frontend, soit en mettant les autres filtres disable si un est déjà sélectionné, soit un tooltip pour informer l’utilisateur – et enlever « no data to display » parce que la cause n’est pas claire pour l’utilisateur.
avantage : on ne touche rien en backend
inconvénient : finalement peu d’intérêt d’avoir plusieurs types de filtres géo ?
Solution 2 :
Pouvoir sélectionner plusieurs types de filtres géographiques à la fois, et tous les critères doivent être vrais ("ET"). Dans l’exemple ci-dessous, cela reviendrait donc à obtenir seulement les observations à Gap, donc l’utilisation de ces 2 filtres n’a pas tellement d’intérêt ici. Mais si on sélectionnait un département ET un PNR, par exemple Isère et PN des Ecrins, on obtiendrait seulement les observations du Parc situées en Isère. Est-ce que ce genre d’utilisation peut avoir une utilité métier ?
avantage : fonctionnalité en plus (utile métier?)
inconvénient : modification des filtres en backend
Solution 3 :
Pouvoir sélectionner plusieurs types de filtres géographiques à la fois, et au moins 1 doit être vrai ("OU"). Dans l’exemple ci-dessous, cela reviendrait donc à obtenir toutes les observations des Hautes-Alpes, donc dans ce cas l’utilisation de ces 2 filtres n’a pas tellement d’intérêt. Mais si on sélectionne des zones qui ne se recouvrent pas, ou partiellement, on peut obtenir une sélection des observations selon une couverture assez fine du territoire.
avantage : pas de modification importante des filtres en backend, grosso modo insérer une liste d’id de zones à la place d’un seul id dans la requête.
inconvénient : utile ?
Solution 4 :
Donner la possibilité à l’utilisateur de choisir le mode de filtrage ("ET" ou "OU") dans l’interface pour les différents types de filtres géographiques.
avantage :
Possibilité de sélectionner les données très finement selon leur localisation
inconvénients :
Complexifie le système de filtres en backend (plus de dev)
Complexifie l’UX
Manque d’homogénéité : car pourquoi ne pas le faire pour d’autres types de filtres (non géographiques) ?
Comment reproduire
The text was updated successfully, but these errors were encountered: