Très bonne question
C’est quand même dommage que le fonctionnement classique de la plupart des utilisateurs soit de passer par une recherche google pour retrouver les itinéraires, simplement car la recherche interne ne fonctionne pas correctement. J’en ai parlé autour de moi, et je ne suis clairement pas le seul à passer par google…
Idem
Ça fait longtemps que j’ai abandonné la recherche interne et passe par Google.
Pour info la recherche sur le site promogrimpe est juste parfaite…
C’est pourtant pas un gros truc comme c2c…
Étrange.
S’en inspirer serait un gros plus.
Petit up rituel.
Et une question au passage : pourquoi ma suggestion n’est pas implémentée ? En vrai, ça ne coûte rien, c’est quelques lignes à modifier, un retour en arrière est facile, et si ça casse la recherche, ce n’est pas trop gênant vu comme elle fonctionne mal actuellement. Et de toute manière, vu la complexité de la modif, ça ne risque pas vraiment de casser quoi que ce soit…
On en avait parlé, mais je ne suis pas dev, je n’ai actuellement pas assez de connaissances. Sinon j’aurais push un truc sur github. Mais je ne sais pas encore faire.
Et sinon, une alternative pour l’instant, que je viens de créer : ajouter un moteur de recherche via les options du navigateur, avec comme requête spécifique
https://www.google.com/search?q=site%3Acamptocamp.org%2Froutes+%s
Associé à un mot clé pratique, ça permet facilement de faire une recherche, uniquement sur les itinéraires (et pas les sorties)
Sinon sur google il y a (aussi pour les sorties) la requete, par exemple pour le mot « bonjour » sur les sorties Camptocamp :
« bonjour » -diff site:www.camptocamp.org/outings
il suffit de mettre « routes », « waypoints » ou « articles » a la place de « outings » - selon le cas.
Merci de vous pencher enfin dessus ! Par contre honnêtement, le fix est discutable (même le mien donnerait de meilleurs résultats je crois) :
Des résultats stricts seraient bien plus propres, vu que dès qu’il y a une modif d’une lettre, ça implose.
Si quelqu’un veut bien m’expliquer comment faire mes propres modifs à la maison, je suis preneur.
edit : j’ai un peu regardé, visiblement Elasticsearch ne supporte pas fuzziness avec type=« phrase » dans une requête multi_match.
edit2 : en fait quand il y a plusieurs mots, l’autocomplétion saute. Je comprends la raison qui vous a poussé à tenter ça mais c’est peu abouti pour l’instant. Donc du ngram basique serait potentiellement mieux, malgré le bruit.
Dans ton exemple, tu recherches « mon blanc » (au lieu de « mont blanc »).
Pas de bol, « mon » est un mot supprimé des mots clés, comme le, la , du, … A moins que ce soit parce qu’il n’a que 3 lettres ?
Par contre quand on cherche « roch blanc » au lieu de « rocher blanc », on trouve bien tout plein de Rocher Blanc.
C’est une grosse amélioration.
Quand on teste les mots clés de ton 1er post (« lau bij »), on trouve direct la voie « Lau Bij ».
En fait en voulant prendre l’exemple le plus banal (et cherché), j’ai pris le pire cas particulier haha
Par contre je ne vois pas d’explication rationnelle au « mont blan » qui n’affiche aucun résultat, et qui soit cohérente avec ce que tu racontes. Pour moi c’est lié au problème du fuzziness qui ne fonctionne plus avec les phrases, comme dit plus haut. Sauf que ça a l’air de fonctionner pour le premier mot. Bref
Bonjour,
Nous avons mis en production hier soir une première version de l’amélioration de la recherche.
C’est particulièrement compliqué car nous souffrons de la vétusté de l’infrastructure.
La ré-indexation de tous les documents est toujours en cours, d’où les comportements erratique, le temps que ce soit réglé.
D’autres évolutions de la recherche sont prévues, avec la montée en version du composant qui gère cela, mais nous la ferons dans un deuxième temps.
Effectivement, le comportement est différent selon que ce soit un mot, ou une phrase
Si jamais, je suis dispo pour vous faire des retours/tests de versions en pré prod, ou je ne sais pas comment vous appelez ça, j’imagine que vous mettez une version en test avant de mettre en prod.
Nous avons déjà fait toute une phase de recette (il y a deux ans, quand le fix a été développé)
Fondamentalement, l’amélioration est géniale par rapport à l’état antérieur, et porte sur un élément crucial du site. Merci!
Une exception pour les mon/mont aurait pu être intéressante, vu que ce mot arrive occasionnellement en montagne, et que ça reste une erreur qu’on voit malheureusement occasionnellement dans les discussions (sisi pour de vrai)
Merci pour le boulot !
Plus on livrera les version ultérieures, mieux ça s’améliorera
Je n’ai pas en tête toutes les modifications qui ont été faites, il faudra voir !
C’est bon, la ré-indexation est terminée, elle a pris plusieurs heures, merci pour votre patience !
J’espère que vous en aurez profité pour remonter un peu dans le passé, c’était l’occasion ! 
Bonne soirée !
Merci beaucoup pour le fix en prod 
A voir à l’usage mais ca semble plutot bien fonctionner pour le moment.
Je remarque juste des comportements étonnants comme l’exemple ci-dessous (même chose avec « cornettes bise » vs « cornettes bis » - peut-être la même chose que « mont/mon » signalé plus haut)
Merci encore @Nayor et @edwardoo pour la mise en prod de cette amélioration tant attendue, mais délicate à passer en prod !
Même si c’est perfectible, c’est quand même vraiment beaucoup mieux qu’avant, y a pas photo.
Pour ceux qui parlent couramment l’Elastic Search et qui veulent améliorer certains petits défauts, la PR contenant les améliorations est ici : https://github.com/c2corg/v6_api/pull/1796
Il suffit de proposer une autre PR pour modifier certains réglages.
Intéressant ce changement. J’avais noté à l’époque quelques mots clés, je vais faire une comparaison dans ce tableau pour montrer la bonne évolution.
Il y a donc le texte, suivi de la position avant, et de la position après le fix.
catogne : 2 et 1 
mole : 2 et « non listé » 
salève : 2 et 1
luisin : 7 et 2
colonney : 5 et 1
prazon : « non listé » et 1
verreu : « non listé » et 1
Le Buet : 3 et 2
Les Pralets : 2 et 1
bionnassay : 7 et 1