https://www.camptocamp.org/waypoints?q=dru
(edit)
[Bug] Recherche topoguide - résultats non pertinents
J’avais eu ces réponses complètement à côté ! Ca m’a poussé à venir en parler, et en refaisant ma recherche de la même manière, je suis tombé sur les résultats de mon screen. Bref ça va pas.
Au pire, Google est ton ami.
Sur le fond, je suis totalement d’accord. La recherche de base est une bouze sur c2c. Mais ça fait 20 ans que je passe par google.
En mettant un espace après, c’est le 2ème résultat.
3 lettres c’est court pour une recherche.
2 Likes
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.
4 Likes
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.
2 Likes
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…
2 Likes
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
2 Likes
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 
3 Likes
Là, tu marques un point.
C’est vrai que l’outil d’association est galère à utiliser, y compris sur un PC.
1 Like