feat: change component to select species (wip)

[andriacap]

• Use same component used in GeoNature

TODO:
-Change the way to filter species programs (do not load all species list but only species exist in program)

-Change the way to display the species in program list

• Check other component which used species list loaded

These following Images show where changes need to be done :

Reviewed-by: andriac

[camillemonchicourt]

A noter que (de mémoire), il y a plusieurs modes existants :

• Si le programme ne contient qu'un seul taxon, alors on ne souhaite pas proposer un champs de recherche de taxon, mais directement affiché le taxon unique
• Si le programme contient moins de 10 (?) taxons, alors on les affiche tous sous forme de vignette
• Si le programme contient plus de 10 taxons, alors c'est uniquement dans ce cas qu'on a une liste pour sélectionner le taxon observé

[lpofredc]

A noter que (de mémoire), il y a plusieurs modes existants :

• Si le programme ne contient qu'un seul taxon, alors on ne souhaite pas proposer un champs de recherche de taxon, mais directement affiché le taxon unique

• Si le programme contient moins de 7 taxons, alors on les affiche tous sous forme de vignette

• Si le programme contient entre 7 et 20 taxons, alors on affiche une liste déroulante (récemment triée par ordre alphabétique)

• Si le programme contient plus de 10 taxons, alors c'est uniquement dans ce cas qu'on a une liste pour sélectionner le taxon observé

Oui, c'est bien ça, avec un niveau supplémentaire intermédiaire de liste déroulante (select html simple).

[hypsug0]

Merci @andriacap!

Quelques retours à chaud et après tests. Comme le précise @camillemonchicourt , le sélecteur d'espèce doit s'adapter en fonction du nombre de taxons de la liste. cf. #381 (comment)

Il est aussi fortement souhaité de conserver la logique actuelle d'une liste de taxon simplifiée et réduite aux nom francais/noms vernaculaire pour éviter de perdre un public de non initiés. Le search_name est trop compliqué et de mon avis source de confusion pour du grand public.

Aussi, il est dommage que cette API ne renvoie pas le nom français qui sert bien souvent à corriger des incomplétudes des nom_vern de taxref ou encore à créer des noms de taxons personnalisés pour des besoins spécifiques.

GeoNature-citizen/frontend/src/app/programs/observations/form/form.component.html

Lines 51 to 59 in 93472ea

	{{
	!!s.nom_francais
	? s.nom_francais
	: s.taxref.nom_vern
	}}
	<span *ngIf="MainConfig.taxonDisplaySciName"
	>(<i>{{ s.taxref.nom_complet }}</i
	>)</span
	>

[camillemonchicourt]

Oui si il y a peu de taxons, une liste est bien mieux qu'un autocomplete où il faut savoir ce que l'on cherche.

[andriacap]

Salut,

Merci pour vos retours .
Alors voici les réponses à vos remarques :

• Ok pour afficher le nom_francais à la sortie de l'autocomplete, C'est possible de jouer sur le formatage du nom
• Concernant les conditions de liste d'affichage des espèces ce qu'il est possible de faire et qui conviendra dans tous les cas énumérés ça serait de faire une requête avec pagination sur la liste et par défaut charger les 20(nombre minimal à définir) premiers taxons avec un scroll "infini" qui charge les taxons de la page suivante

Dans tous les cas où pourrait gagner en performance à ne pas charger l'ensemble de la liste de taxons Et de ses médias . Requête qui est faite à l'initialisation même d'un programme alors qu'on n'affiche rien coté frontend à ce moment là.

Du coup quel serait votre avis par rapport aux propositions de chacun de ces composants ci dessous :

1. Composant de recherche pour l'ajout d'une espèce (ajout d'une observation à un programme)

• Option 1 : Liste paginée avec un chargement des XX (20 premiers ?) taxons au click sur le composant de recherche avec un scroll infini
  (lorsque l'utililsateur atteind l'affichage du dernier élément de la liste de 1ère page chargée on fait la requête pour la seconde page)
• Option 2 : Affichage conditionnel de composant de recherche d'espèces (avec les cas énumérés ci dessus par Camille + Rajout d'une condition si nb d'espèces > 100(?) taxons alors composants d'autocomple proposé dans cette PR avec modification du nom affiché en nom français)

2. Composant de filtre (d'espèces) sur les observations d'un programme

• Liste proposant uniquement les espèces qui sont associées aux observations du programme ( se passer de la liste entière lié à un programme et donc ne charger que les espèces filtrables)

3. Composant d'affichage de la liste des observations ajoutées

Voir liste des observations sur l'image ci dessus. Se baser uniquement sur les informations récupérées sur la route GET des observation du programme sélectionné ( se passer de la liste entière lié à un programme et donc ne charger que les informations utiles à l'affichage coté frontend)

Encore merci pour votre réactivité et vos retours

[camillemonchicourt]

Attention, on n'utilise jamais le champs "bib_noms_nom_francais" dans GeoNature ni GeoNature-atlas, car nous sommes en train de supprimer la table "bib_noms" de TaxHub qui pose trop de soucis et complique les choses.
Donc je déconseille de s'appuyer dessus dans GeoNature-citizen.

Si on est dans un programme mono-espèce avec un seul taxon (cas fréquent), c'est vraiment dommage d'afficher une liste déroulante avec un seul taxon, ça porte à confusion.

Si on n'a que 4 ou 5 espèces, c'était sympa d'afficher uniquement des petites vignettes les unes à côtés des autres, plutôt qu'uune liste déroulante. Mais là c'est secondaire.

[krebs-m]

Bonjour,

Concernant le composant de recherche pour l'ajout d'une espèce, l'option 2 qui permet d'avoir l'autocomplétion sur une liste d'espèce de plus de 100 taxons tout en gardant les vignettes et la liste lorsque le nombre de taxons est inférieur à 100, nous semble le plus pratique côté utilisateur. La liste paginée de l'option 1 obligerait les observateurs à trop scroller, surtout si l'espèce recherchée est en bas de la liste.

Pour le filtre dans la liste des observations, effectivement ne faire apparaître que les espèces qui ont été saisies est suffisant.

Merci à vous!

[andriacap]

Bonjour ,

Je me permet de relancer cette conversation concernant le fait d'avoir la possibilité d'associer des listes de taxons à des programmes qui sont supérieur à 100 .

Est ce que ça vous semble ok de votre coté ( @lpofredc , @hypsug0 , @camillemonchicourt ) si :

• On change la manière de charger la liste des espèces lié à un programme (sauf erreur de ma part à l'heure actuelle toutes les espèces sont chargées au moment du chargement du programme ) et implique du coup un changement sur plusieurs composant
  Cela concerne :
• Le Composant de Recherche d'espèce lors de l'ajout d'une observation
  • On a un affichage conditionnel où l'on garde l'affichage de vignette pour liste inférieur (de >5 à <=20 par exemple mais à définir)
  • Affichage des vignettes directement sans liste déroulante si nb d'espèce <= 5
  • Utilisation d'un composant avec autcomplete pour chercher une espèce parmi une liste d'espèce comprenant plus de 20 taxons (à définir pour le nombre minimum où l'on passerait sur ce composant)
• Le Composant de recherche d'espèces appartenant à un programme et servant de filtre lorsqu'on arrive sur un programme (même remarque ici , sauf erreur de ma part l'ensemble des espèces sont chargées alors que l'on ne peut filtrer que sur les espèces que l'on a observées).

Si c'est Ok de votre coté (@lpofredc , @camillemonchicourt , @hypsug0 ) on pourra débuter de notre coté la contribution sur le sujet

Merci d'avance pour vos retours

[camillemonchicourt]

OK pour moi.
Mais pour le composant de recherche d'espèces dans la liste des observations devrait ne proposer que les espèces observées au moins une fois.

Et sauf erreur de ma part pour les programmes mono-espèces, actuellement on affiche la vignette de l'espèce mais il n'est pas nécessaire de le sélectionner car le programme ne contient qu'un seul taxon.

PR liée à #327

[lpofredc]

Bonjour, réponse brève car en congés. En effet, @camillemonchicourt a raison pour les programmes mono taxon. Je n'ai pas eu le temps d'analyse en détails les impacts de ces changements. Ce qui me chiffonne, c'est la disparition de l'usage du champ nom français lie a bibnoms beaucoup utilise dans les listes citizen, notamment pour cibler des rangs taxonomiques supérieurs (ex "dragon" dans le programme national un dragon dans mon jardin, "chauve-souris" dans des enquêtes génériques chiro, etc.). A minima, il faudrait un attribut taxhub pour compenser cette perte.

[camillemonchicourt]

Oui tout a fait, la piste d'un attribut a été évoquée (PnX-SI/TaxHub#309), mais clairement bib_noms ça fait un modèle et de la gestion complexe pour les utilisateurs, pour les migrations Taxref, etc, et il est bienvenue de s'en séparer. 😀

[andriacap]

Bonjour,

Après réflexion et discussion avec @lpofredc il est ressorti que le plus simple serait d'ajouter la gestion de params pour l route d'autcompletion liée à TaxHub `allnamebylist`` https://github.com/PnX-SI/TaxHub/blob/ca38000d89c074cfba9c80965ab11d9ef679c3ce/apptax/taxonomie/routestaxref.py#L378-L396

L'idée étant de rajouter la possibilité de récupérer les médias (photo_principale) et le "nom_français" .
Pourquoi vouloir ajouter ces pararms ? Car dans GN Citizen on doit récupérer les médias et les nom français associés aux taxons pour les afficher coté frontend .

Cette modification permettrait d'éviter de complexifier les appels en chaine de différentes routes pour récupérer d'une part les taxons (cd_nom etc) et d'autre part les médias associés

Si c'est ok , on partirait sur une modif coté TaxHub et une modif coté GN Citizen
Merci pour vos retours.

@camillemonchicourt @lpofredc