En mettant un espace après, c’est le 2ème résultat.
3 lettres c’est court pour une recherche.
[Bug] Recherche topoguide - résultats non pertinents
Je trouve le résultat après d’autres qui n’ont rien à voir. La mise à jour aurait du corriger ça.
C’est ce que je fais depuis quasi toujours, et c’est à l’origine de la création de ce topic. Mais il y a eu une mise à jour, je fais juste un retour sur la maj, à l’attention des devs qui ont bossé dessus.
Bien vu, s’il n’y a que ça à faire, alors c’est top. Donc dans l’immédiat, problème corrigé (il suffit de faire une recherche exacte et mettre un espace après, ça me convient parfaitement, tant que les accents sont ignorés), mais problème il y a dans l’absolu.
Toujours mettre un espace après, même pour un mot de 6 lettres, pour être sûr que toutes les lettres soient prises en compte. Pas seulement pour le traitement dans le serveur, mais parfois juste pour que le navigateur (le script JS dans la page c2c) se réveille pour envoyer une requète.
-
'dr': le navigateur envoie'dr'. -
'dru': il devrait envoyer'dru'mais il a la flemme. -
'dru ': il se réveille, il envoie'dru'(ou'dru ', l’espace en début/fin de ligne est peut être supprimé dans le navigateur).
Ça fait longtemps que mettre une espace (attention: une!) après la recherche est une bonne astuce pour améliorer la recherche sur C2C. Le seul problème, c’est que l’utilisateur normal n’en a aucune idée, et que c’est lui qui a raison.
Je viens de voir 2 cas où la nouvelle recherche ne fonctionne pas bien :
- ne trouve pas le Rifugio Biella, en tapant tout, alors qu’il existe et est nommé comme ça
- Idem pour Riva di Tures
Je viens de comprendre pourquoi ça ne marche pas dans les cas ci-dessus, ainsi que d’autres similaires.
La recherche cloisonne les langues. Dans les cas ci-dessus il n’y a pas le doc en français. Si je crée une traduction en français, ça le trouve bien depuis mon interface en français.
A voir si ça peut être corrigé facilement sans effet de bord.
Ce défaut existe sur la recherche rapide en haut de page.
Sur la recherche avancée, ça cherche dans toutes les langues : https://www.camptocamp.org/waypoints?q=Rifugio%20Biella
Au passage, j’ai traduit la page du refuge en fr, it, de. Le site web du refuge est en it et en.
Le document étant quasi vide en français et en anglais, ce serait préférable d’effacer ces 2 versions linguistiques. La seule information textuelle en français/anglais est la période d’ouverture qui n’est pas une information pérenne mais doit se chercher sur le siteweb du refuge.
Toutes les autres informations sont traduites automatiquement dans la langue de l’interface. Les versions allemande et italienne sont donc suffisantes, en plus d’être juste (avec le bon nom) et permettent de lire les informations traduites automatiquement dans les 10 langues c2c.
Il y a probablement un gros travail sur les points de passages en supprimant toutes les versions linguistiques vides avec un nom dans une autre langue et ne servant donc à rien, voir polluant la base et créant des faux problèmes (cf discussion sur les sommets multilingues).
Une version linguistique ne devrait être créée qu’il s’il y a des informations textuelles (hors champs traduit automatiquement) et pérennes dans la langue correspondante.
Un soucis que je viens de rencontrer : ni « Haafniouf » ni « Haâfnïouf » ne permettent de trouver https://www.camptocamp.org/routes/57490/fr/presles-buis-haafniouf dans la recherche rapide du haut à droite, mais le trouvent bien dans la recherche d’itinéraires.
Google est ton ami pour les recherches simples sur un nom https://www.google.com/search?q=Haâfnïouf+camptocamp
Le but c’est précisément de ne plus devoir passer par google…
Je ne suis pas persuadé que cela soit un sujet prioritaire., ni même important.
La recherche c2c sur mot simple a tjrs fonctionné bien moins bien que Google. Avec les LLM et pour la recherche sur des zones de textes (le nom est du texte), il est quasi certains que la différence va encore s’amplifier et probablement de manière exponentielle.
AMA, il est préférable d’avancer sur l’intégration de recherche externe « moderne », et notamment par LLM, que de vouloir faire aujourd’hui ce que nous n’avons pas réussi à faire en 25 ans.
Ceci étant dit, s’il y a des bugs facile à résoudre, il ne faut pas se priver.
Edit : je viens de tester un LLM, ça passe sans soucis, y compris avec un nom approximatif.
Alors t’es pas sur le bon fil de discussion

Merci pour ta contribution
Effectivement. Si la recherche avancée utilise aussi Elastic Search, il doit y avoir moyen de reproduire ce fonctionnement sur la recherche rapide.
Le pb existe aussi pour la recherche du point de passage dans l’outil d’association : grosse galère pour associer les WP à mes itinéraires, car l’outil (identique à la recherche rapide a priori) ne les trouvait pas. Obligé d’aller chercher l’ID du point de passage en question (sur téléphone, faut vraiment être motivé ou avoir du temps pour aller au bout de l’opération).
Et là-dessus, c’est pas Google ou les LLM qui vont nous aider 
Là, tu marques un point.
C’est vrai que l’outil d’association est galère à utiliser, y compris sur un PC.
Hello,
J’ai fait un « quickfix » qui permet de chercher dans d’autres langues que celle du navigateur, en boostant tout de même celles qui matchent le language d’utilisation.
À tester
Yoann
Pour la recherche en tant que telle, les évolutions à venir sur Elastic vont permettre de rattraper quelque peu le retard pris depuis 2017. Pour l’instant j’essaye juste de mettre en production ce qui a été réalisé il y a 1-2 ans, mais il y a sûrement manière à se pencher sur le sujet pour améliorer encore la recherche. Chaque chose en son temps ^^
Quoi qu’il arrive, elle restera moins bonne que celle de Google
Quand à utiliser des LLM… un peu overkill non ? Dans tous les cas, c’est sûr que ça sera beaucoup plus lourd à mettre en place que de faire évoluer la recherche actuell
Je rencontre un autre soucis inattendu : ni « Rivière » ni « Kwaï » ne proposent https://www.camptocamp.org/routes/57824/fr/vallee-d-ailefroide-orage-d-etoiles-riviere-kwai dans la recherche rapide, alors que ca propose https://www.camptocamp.org/routes/1308323/fr/kwale-legion-college-de-doujani
Merci pour le retour
Effectivement, la recherche rapide a un comportement différent, j’ai fait un autre fix, à tester / livrer, mais nécessite une réindexation.
Cela dit, le coeur du problème c’est qu’elastic ne cherche que 2 mots similaires à celui tapé avant de faire sa recherche. J’ai fait un fix pour passer à 50 mots (valeur par défaut).
Idem, à merger, tester, prise en compte immédiate (pas besoins de réindexer)