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.
Toutes les adresses n'ont pas de numéro de rue. Les routes rurales, certains nouveaux lotissements et les lieux emblématiques connus sont souvent désignés sans numéro, et une requête de géocodage conçue pour attendre un numéro à chaque fois interprétera mal ce à quoi ressemble un résultat valide dans ces cas.
GET /v1/forward?q=Golden Gate Bridge, San Francisco&limit=1{
"status": "ok",
"query": "Golden Gate Bridge, San Francisco",
"results": [
{
"formatted": "Golden Gate Bridge, San Francisco, CA",
"lat": 37.8199,
"lon": -122.4783,
"type": "address",
"precision": "street",
"confidence": 0.9,
"place_id": "gb567",
"components": {"city": "San Francisco", "region": "CA", "country": "US"}
}
]
}Remarquez qu'il n'y a pas de champ house_number dans components ici, et que precision indique « street » plutôt que « house ». Les deux sont normaux pour une adresse qui n'a réellement pas de numéro de rue, et ne sont pas le signe d'une recherche échouée ou partielle.
Considérez precision comme une description du niveau de détail de la correspondance, et non comme un indicateur d'erreur. Une précision « house » signifie que la correspondance a abouti à un bâtiment précis. Une précision « street » signifie qu'elle a abouti à une rue ou à un point le long de celle-ci, sans identifier un bâtiment exact, ce qui est tout à fait correct pour un lieu emblématique ou une adresse réellement dépourvue de numéro de rue.
GET /v1/forward?q=Central Park, New York&limit=1Un espace public nommé comme celui-ci est généralement résolu avec un type plus large que « address » et une précision qui reflète une zone plutôt qu'un point unique, avec un objet components qui peut ne contenir qu'une ville et une région. C'est le même schéma que dans l'exemple du pont : un résultat réel et utile, décrit honnêtement comme couvrant une zone plutôt qu'un bâtiment précis, parce que c'est bien ce à quoi la requête faisait référence.
Si la validation de votre formulaire exige actuellement la présence d'un champ house_number avant d'accepter une adresse comme complète, cette vérification rejettera à tort des adresses rurales et des lieux emblématiques légitimes. Fondez vos critères d'acceptation sur une confiance et une précision correspondant à vos besoins réels, plutôt que d'exiger que chaque composant spécifique soit renseigné.
Ne considérez pas un objet components vide, ou auquel manquent plusieurs champs, comme l'équivalent d'une requête échouée. Une requête échouée revient avec un statut d'erreur et un code d'erreur, décrits dans la documentation des erreurs. Un résultat réussi avec peu de composants est une issue différente et tout à fait normale, et confondre les deux dans votre gestion des erreurs fera enregistrer et traiter des adresses valides comme des échecs.
Pour une adresse sans numéro de rue, présenter le résultat formaté au client pour qu'il le confirme fonctionne mieux que de rejeter purement et simplement la saisie. Une adresse réelle reste ainsi utilisable, tandis que les saisies réellement erronées sont toujours détectées par ailleurs.
Le géocodage inverse d'une coordonnée située en pleine campagne ou sur l'eau peut lui aussi revenir avec une précision plus grossière et moins de composants renseignés qu'une coordonnée située sur l'emprise d'un bâtiment précis. La documentation du géocodage inverse décrit les mêmes valeurs de précision dans ce sens.
Une adresse sans numéro de rue coûte la même requête unique que toute autre recherche de géocodage direct. L'absence de composants ne change rien à la façon dont la requête est décomptée de votre quota quotidien ou de votre solde de crédit.
Bien gérer ce cas consiste surtout à lire precision et confidence comme prévu, plutôt que de supposer que toute adresse valide doit renseigner entièrement chaque composant. La documentation du géocodage direct explique chaque champ en détail.