À propos de la recherche

laem

Quelques notes sur la recherche. C'est un élément crucial de l'application.

On a la chance d'avoir Photon, par Komoot. C'est un logiciel incroyable par rapport à ce qu'il y avait avant.

Cependant, il n'a pas la puissance de Google notamment pour faire la part entre les recherches locales et les recherches globales. D'où le bouton "rechercher ici", qu'il faudrait peut-être revoir (son texte, son style, icône, etc) mais qui est incontournable à ce stade.

Voici les tickets ouverts au sujet de la recherche : https://codeberg.org/cartes/web/issues?state=open&type=all&labels=1331235

1. etienneJr

   Je découvre que photon a déjà des options pour faire des requêtes plus ciblées, par exemple en filtrant par tag osm, ou par niveau de lieu (rue, quartier, ville). Est ce déjà utilisé ?

   Je me dis qu'on pourrait pré-analyser le texte pour appliquer des filtrages, par ex :

   • filter sur layer=street quand la requête inclut les mots rue, avenue, boulevard, place,...
   • filter sur tag swimming_pool quand la requête inclut piscine, etc : il faudrait pouvoir réutiliser le dictionnaire des catégories pour avoir la correspondance entre synonyme et tag.

   En fait, pour éviter les échecs, il faudra toujours lancer une requête globale en parallèle de la requête ciblée, pour l'afficher si la requête filtrée ne donne rien. Si les 2 ont des résultats, on affiche en premier ceux de la requête ciblée.

   Dans la même idée, je me dis qu'il doit être très très classique de chercher une ville. On pourrait toujours lancer une requête filtrée sur layer=city. Si il y a un match on l'affiche en premier avant les résultats de la recherche globale.

   Évidemment si on fusionne des résultats de plusieurs requêtes, il faudra éliminer les doublons.

2. laem

   D'ailleurs à ce propos, on a déjà un peu d'intelligence en plus dans la recherche, voir la détection d'itinéraires et de code postal. https://github.com/cartesapp/cartes/blob/master/app/PlaceSearch/index.tsx#L132-L183

   Je suis à fond pour ajouter la détection de types de lieux pour palier aux défauts de Photon, style "Hotel Tipi" qui n'est pas trouvé mais qui le serait avec "catégorie=hotel" + "nom=Tipi" https://forum.openstreetmap.fr/t/une-recherche-dhotel-infructueuse/32686

3. etienneJr

   j'ai regardé photon, je crois qu'il va me manquer les scores des résultats dans chaque requête pour pouvoir fusionner intelligemment les résultats, j'ai posé la question ici : https://github.com/komoot/photon/discussions/911

4. laem

   Par contre je crois qu'il y a deux freins à l'utilisation de ces structured queries. L'une est qu'il faut qu'on importe la base de données nous mêmes plutôt que de simplement télécharger l'archive. L'autre qu'il faut passer à la version OpenSearch expérimentale.

5. etienneJr

   Je pense qu'on n'a pas besoin des structured search. C'est fait pour chercher street=xx dans city=yy. Ça impliquerait, pour écrire la requête, qu'on prétraite l'input pour identifier quel mot est la ville et quel mot est la rue, c'est trop compliqué.

   Je pensais plutôt utiliser les requêtes classiques, filtrées par tag ou par layer, par ex : q=rennes&layer=city&layer=locality

6. etienneJr

   Un autre cas de recherche foireuse signalé ici : https://forum.openstreetmap.fr/t/recherche-et-affichage-de-communes-anciennes-communes/35148

7. etienneJr

   J'ai eu une autre idée d'implémentation. On garde la recherche actuelle au début. Mais on chronomètre le temps passé depuis la 1ère lettre tapée. Si l'utilisateur n'a pas trouvé au bout de 15s, on affiche un message et des boutons:

   Le monde est grand, j'ai besoin d'un peu d'aide. Cherchez vous une ville ? Une adresse ? Un magasin ?
   

   Le défaut : ça envoie le message que notre recherche est un peu pourrie... @laem un avis ?

8. laem

   Mmh, pas convaincu car dans de nombreux cas 15 secondes c'est beaucoup trop (l'utilisateur sera déjà passé à autre chose, aura dézoomé par exemple) et dans d'autres c'est trop peu. Les UX qui chronomètrent sont pour cette raison très compliquées à gérer, on peut déclencher des effets de bord non désirés.

   À mon avis une mise en avant du bouton "rechercher ici" pourrait résoudre l'essentiel du problème, et une deuxième requête photon sur les villes seulement à mélanger aux résultats de la recherche locale en position 1 ou 2 pourrait en résoudre 80%, non ?

9. etienneJr

   Les UX qui chronomètrent sont pour cette raison très compliquées à gérer

   OK je n'avais pas ça en tête.

   À mon avis une mise en avant du bouton "rechercher ici" pourrait résoudre l'essentiel du problème,

   Ça me fait penser que chez moi, il est la plupart du temps caché par le clavier... Il faudrait le remonter au niveau de la barre de recherche. Peut être avec un sélecteur à 2 positions ici o=o partout

   une deuxième requête photon sur les villes

   Ah oui c'est vrai, j'avais dit que je le ferai, et j'ai même pas commencé parce que l'instance était buguée...

10. etienneJr

    j'ai commencé une première amélioration dans #1231 : si on repère les mots "rue", "avenue", etc, on fait la recherche uniquement parmi les rues (c'est pas optimal car on perd les magasins dont le nom contient avenue).

    Ca m'a donné une nouvelle idée d'UX : on transforme la coche "chercher ici" en un sélecteur partout / ici / adresse / ville. Si le script repère le mot rue, il active le sélecteur sur adresse, mais l'utilisateur pourra ensuite rebasculer sur partout ou ici.

    @laem ton avis ?