Surveillez l'utilisation de votre clé avant d'atteindre une limite
Surveiller vos en-têtes de quota au fil de l'eau vous indique quand une limite approche, bien avant qu'une requête ne soit effectivement refusée.
Une entreprise qui compte quelques bureaux n'a besoin de rien de sophistiqué pour répondre à la question « quel est le bureau le plus proche de chez moi » : une seule requête de géocodage et une courte comparaison avec une liste qui change rarement suffisent.
Que le visiteur saisisse une adresse ou un code postal, géocodez-le pour obtenir des coordonnées.
GET /v1/forward?q=Berlin, Germany&limit=1{
"status": "ok",
"results": [
{"formatted": "Berlin, Germany", "lat": 52.5200, "lon": 13.4050, "type": "locality", "precision": "city", "confidence": 0.85, "place_id": "bl456", "components": {"city": "Berlin", "country": "DE"}}
]
}Conservez les coordonnées de vos bureaux sous forme d'une petite liste fixe dans votre propre code ou votre configuration, car elles changent rarement et n'ont pas besoin d'une recherche à chaque fois.
offices = [
{"name": "Berlin", "lat": 52.5170, "lon": 13.3888},
{"name": "Paris", "lat": 48.8566, "lon": 2.3522},
{"name": "London", "lat": 51.5074, "lon": -0.1278}
]Calculez la distance entre les coordonnées du visiteur et chaque bureau à l'aide de la formule de haversine classique, puis triez par distance et renvoyez le résultat le plus proche.
Au lieu d'une simple zone de texte, adosser le champ de localisation à /v1/autocomplete permet au visiteur de choisir parmi des lieux suggérés au fil de sa saisie, ce qui réduit le risque qu'une faute de frappe produise un résultat de géocodage inattendu. Une fois une suggestion sélectionnée, résoudre son place_id ou son texte via le même flux de géocodage direct alimente directement la comparaison de distances déjà décrite.
Notez que la précision dans l'exemple ci-dessus est « city » plutôt que « house », puisque le visiteur n'a saisi qu'un nom de ville. Cela convient pour un outil de recherche de bureau, où l'objectif est de choisir le bureau le plus proche parmi quelques options, et non de localiser un bâtiment précis. Une précision plus grossière ne demande ici aucun traitement particulier, contrairement à ce qui pourrait être le cas pour une adresse de livraison.
N'oubliez pas de mettre à jour la liste fixe de bureaux dans votre propre code lorsqu'un bureau physique ouvre, ferme ou déménage. Comme la liste se trouve dans votre propre configuration et non dans l'API, elle peut facilement devenir obsolète sans que personne ne s'en aperçoive, orientant discrètement les visiteurs vers un site fermé ou excluant totalement un nouveau site de toutes les comparaisons. Considérez cette liste comme faisant partie de la revue régulière de votre contenu, et non comme une étape de configuration ponctuelle.
Un nom de lieu court peut parfois correspondre à plusieurs lieux réels, par exemple un nom partagé entre un pays et une région sans rapport située ailleurs. Transmettre le paramètre countries pour limiter les correspondances candidates aux pays où vous avez réellement des bureaux évite que ce type d'ambiguïté ne soit résolu à l'autre bout du monde.
Afficher les deux ou trois bureaux les plus proches, plutôt que le seul plus proche, permet à un visiteur situé près d'une frontière régionale de choisir celui qui lui convient vraiment, par exemple un bureau dont la langue ou le fuseau horaire lui correspond mieux, même s'il est un peu plus éloigné.
Chaque recherche correspond à une requête de géocodage. La comparaison avec votre liste de bureaux se fait ensuite entièrement dans votre propre code et n'ajoute rien à votre nombre de requêtes. Une page de ce type, même avec un trafic régulier, reste largement dans les 2 500 requêtes gratuites par jour incluses avec chaque clé.
Un outil de recherche du bureau le plus proche conçu de cette façon nécessite exactement une requête par recherche d'un visiteur, toute la logique de comparaison restant de votre côté. Les détails sur le format des requêtes figurent dans la documentation du géocodage direct.