Le service Nominatim n’est pas conçu pour de l’auto-complétion, et donc dans le cas de ce fournisseur nous effectuons la recherche quelque millisecondes seulement après que le texte soit entré, ce qui peut donner une impression de lenteur.
Si jamais les mêmes requêtes sont effectuées souvent, Mobilizon pourrait effectivement bénéficier d’un système de cache.
Pour éviter les limitations de Nominatim, nous utilisons sur https://mobilizon.fr le service Pelias, mais cela consomme beaucoup de ressources donc nous nous limitons aux données européennes.
Pour une instance à destination d’un public français uniquement, il est notamment possible d’utiliser le géocodeur Addok avec le service adresse.data.gouv.fr. Sinon il n’y a pas beaucoup d’autres options en services qui ne nécessitent pas un investissement et qui ne sont pas Google.
Si jamais les mêmes requêtes sont effectuées souvent, Mobilizon pourrait effectivement bénéficier d’un système de cache.
Il s’agirait donc d’une amélioration ? Si c’est le cas, je jetterai un coup d’œil au code, pour voir si c’est difficile.
Nous sommes en Suisse, donc 90% ou plus de nos utilisateurs chercheront les mêmes 5-10 villes. Peut-être devrais-je envisager de les implémenter sous la forme d’une liste énumérée à la place.
Finally, the Pelias approach is lovely, complete, and a remarkable project.
But what I think mobilisons.ch needs is something simple, inflexible, and hacky. I’m going to build a mini-api proxy which will cache literal json responses from Nominatum, and return the cached version first. I’m tempted to do this at the network layer just to avoid getting into the Mobilizòn code.
On the other hand I’m tempted to use a built-in solution as a first contribution to Mobilizòn.