À propos de la recherche
publié le , mis à jourQuelques 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
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.
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
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
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.
Je pense qu'on n'a pas besoin des structured search. C'est fait pour chercher
street=xxdanscity=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=localityUn autre cas de recherche foireuse signalé ici : https://forum.openstreetmap.fr/t/recherche-et-affichage-de-communes-anciennes-communes/35148
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 ?
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 ?
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 partoutune 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...
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 surpartoutouici.@laem ton avis ?
@etienneJr wrote in https://codeberg.org/cartes/web/issues/399#issuecomment-5411706:
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
attention, tous les tags ne sont pas pris en charge, ça dépend des tags inclus dans la base nominatim qui a servi à construire la base photon. Le réglage par défaut est ici (si j'ai bien compris) : https://github.com/osm-search/Nominatim/blob/master/lib-lua/themes/nominatim/presets.lua#L150-L242
Ah merci ! Mince, quel bordel d'avoir juste une sélection éditoriale de certains tags. Je me demande si c'est pas plus simple pour beaucoup de nos catégories de lancer la recherche Overpass sur la requête categories.yaml puis de filtrer ensuite les noms via Fuse, qui est de toutes façons déjà chargée dans l'app.
Bonus : on peut alors utiliser les attributs que Photon ignore, comme "short_name" https://github.com/komoot/photon/issues/934#issuecomment-4753479357.
Finalement, ça reviendrait à proposer une "recherche profonde", plus lente que la recherche de base, mais assistée et complète.
Bien sûr avec la limitation du zoom suffisant pour chercher. Mais y a moyen que ça couvre 90 % des besoins. Quand on cherche "boulangerie du Thabor", on est déjà a priori à un niveau de zoom élevé.
Quoique, beaucoup de gens doivent avoir le réflexe Googlesque de chercher ça avec un zoom sur la France. Mais bon, on résoudrait au moins une partie du problème et ce de façon générique pour toutes nos catégories.
@laem wrote in https://codeberg.org/cartes/web/issues/399#issuecomment-17935748:
quel bordel d'avoir juste une sélection éditoriale de certains tags.
D'ailleurs Sarah déconseille le filtre par tag... Il faut utiliser les... catégories photon 😅 https://github.com/komoot/photon/discussions/1092#discussioncomment-17403471 Mais techniquement je ne sais pas si on peut le faire en utilisant les exports graphopper
Ah mais il est très intéressant ce commentaire, surtout la seconde partie.
Mais du coup, ces catégories "osm.<key>.<value>", elles incluent seulement celles spécifiées dans le dico de ton lien plus haut ?
@laem wrote in https://codeberg.org/cartes/web/issues/399#issuecomment-17939039:
Mais du coup, ces catégories "osm..", elles incluent seulement celles spécifiées dans le dico de ton lien plus haut ?
Non, j'ai l'impression que c'est toi qui les définis après coup, donc que tu peux faire ce que tu veux.