Guides

Géocoder en inverse une liste de coordonnées sans écrire de boucle

Si vous avez une table de paires latitude et longitude et un script qui appelle l'API une fois par ligne, vous payez pour les allers-retours, pas pour les recherches elles-mêmes. L'endpoint de géocodage inverse accepte un corps POST groupé de la même façon que l'endpoint de géocodage direct, et résout chaque paire en un seul appel.

Envoyer des paires de coordonnées

Au lieu d'une requête GET par point, envoyez un tableau d'objets de coordonnées à /v1/reverse. Chaque élément renvoie sa propre adresse, dans l'ordre où il a été envoyé.

POST /v1/reverse
Content-Type: application/json

[{"lat": 48.8584, "lon": 2.2945}, {"lat": 40.6892, "lon": -74.0445}]
{
  "status": "ok",
  "results": [
    {"formatted": "Champ de Mars, Paris, France", "lat": 48.8584, "lon": 2.2945, "type": "address", "precision": "street", "confidence": 0.9, "place_id": "gh789", "components": {}},
    {"formatted": "Liberty Island, New York, NY", "lat": 40.6892, "lon": -74.0445, "type": "address", "precision": "street", "confidence": 0.88, "place_id": "jk012", "components": {}}
  ]
}

Pourquoi c'est mieux qu'une boucle

Une boucle qui envoie une requête HTTP par coordonnée ajoute une surcharge de connexion pour chaque ligne et complique le suivi de votre quota quotidien, puisque vous regardez défiler les en-têtes de centaines de réponses distinctes au lieu d'une seule. Un appel groupé unique facture toujours une requête par élément, donc le coût total sur votre quota est identique, mais vous n'avez qu'un seul jeu d'en-têtes de quota à lire et un seul endroit où intercepter les erreurs.

Lire la réponse

Chaque résultat du tableau correspond à la coordonnée envoyée à la même position. Si un point se trouve dans un endroit sans adresse proche, comme en pleine mer ou dans une vaste zone non cartographiée, attendez-vous à un score de confiance plus faible ou à une valeur de précision plus grossière plutôt qu'à une erreur : vérifiez donc ces deux champs avant d'utiliser l'adresse formatée dans tout ce qui est visible par vos clients.

Un second exemple : associer des données de fuseau horaire

Une fois que vous avez les adresses d'une liste de coordonnées, une étape courante consiste à savoir quelle heure il est à chacune d'elles. Plutôt que de parcourir les résultats une seconde fois dans une boucle, envoyez la même liste de coordonnées à /v1/timezone dans sa propre requête groupée. Vous obtenez deux tableaux alignés, les adresses de /v1/reverse et les identifiants de fuseau horaire de /v1/timezone, tous deux dans l'ordre d'origine des lignes, pour un coût d'une requête par point et par endpoint.

Une erreur à éviter

Ne supposez pas que chaque coordonnée de votre table est valide avant de l'envoyer. Une latitude hors de l'intervalle -90 à 90 ou une longitude hors de l'intervalle -180 à 180, ce qui arrive plus souvent qu'on ne le voudrait lorsque des colonnes sont inversées dans un tableur, compte quand même comme une requête alors qu'elle ne peut renvoyer aucun résultat cohérent. Vérifiez les plages dans votre propre code avant l'envoi du lot, plutôt que de payer pour une recherche qui n'avait aucune chance d'aboutir.

Dimensionner vos lots

Il n'est pas nécessaire d'envoyer toute une table de base de données en une seule requête. Regroupez les coordonnées en lots dimensionnés selon les limites de mémoire et de délai d'attente de votre propre script, et suivez le nombre de requêtes que chaque lot consomme sur le quota gratuit quotidien ou sur votre solde de crédit. Les en-têtes X-Quota-Used et X-Quota-Free-Remaining de chaque réponse vous indiquent exactement où vous en êtes avant d'envoyer le lot suivant.

Effectuer ainsi le géocodage inverse d'une liste complète transforme ce qui était autrefois une boucle lente en une requête par lot, l'API effectuant de toute façon le même travail par élément. Tous les détails des requêtes et des réponses se trouvent dans la documentation du géocodage inverse.