Controla el uso de tu clave antes de alcanzar un límite
Vigilar las cabeceras de cuota sobre la marcha te indica cuándo te acercas a un límite, mucho antes de que se rechace realmente una solicitud.
Geocodifica de forma inversa una lista de coordenadas sin escribir un bucle
Si tienes una tabla de pares de latitud y longitud y un script que llama a la API una vez por fila, estás pagando por los viajes de ida y vuelta, no por las consultas en sí. El endpoint de geocodificación inversa acepta un cuerpo POST masivo igual que el endpoint directo y resuelve todos los pares en una sola llamada.
Enviar pares de coordenadas
En lugar de una solicitud GET por punto, envía un array de objetos de coordenadas a /v1/reverse. Cada elemento devuelve su propia dirección, en el orden en que se envió.
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": {}}
]
}Por qué es mejor que un bucle
Un bucle que lanza una solicitud HTTP por coordenada añade la sobrecarga de conexión en cada fila y hace más difícil controlar tu cuota diaria, ya que ves pasar las cabeceras de cientos de respuestas separadas en lugar de una. Una sola llamada masiva sigue cobrando una solicitud por elemento, así que el coste total contra tu cuota es idéntico, pero tienes un único conjunto de cabeceras de cuota que leer y un único lugar donde capturar errores.
Leer la respuesta
Cada resultado del array se corresponde con la coordenada que enviaste en la misma posición. Si un punto cae en algún lugar sin direcciones cercanas, como en mar abierto o en una gran zona sin cartografiar, espera una puntuación de confianza más baja o un valor de precisión más general en lugar de un error, así que comprueba ambos campos antes de usar la dirección formateada en cualquier cosa que vea el cliente.
Un segundo ejemplo: combinarlo con datos de zona horaria
Un paso habitual una vez que tienes las direcciones de una lista de coordenadas es averiguar qué hora es en cada una. En lugar de recorrer los resultados una segunda vez, pasa la misma lista de coordenadas a /v1/timezone como una solicitud masiva propia. Obtienes dos arrays alineados, direcciones de /v1/reverse e identificadores de zona horaria de /v1/timezone, ambos en el orden original de las filas, con un coste de una solicitud por punto y por endpoint.
Un error que conviene evitar
No des por hecho que todas las coordenadas de tu tabla son válidas antes de enviarlas. Una latitud fuera del rango de -90 a 90 o una longitud fuera del rango de -180 a 180, algo que ocurre más a menudo de lo que debería cuando se intercambian columnas en una hoja de cálculo, sigue contando como una solicitud aunque no pueda devolver un resultado lógico. Comprueba los rangos en tu propio código antes de enviar el lote, en lugar de pagar por una consulta que nunca iba a funcionar.
Dimensionar los lotes
No hace falta enviar toda una tabla de la base de datos en una sola solicitud. Agrupa las coordenadas en lotes dimensionados según los límites de memoria y de tiempo de espera de tu propio script, y lleva la cuenta de cuántas solicitudes consume cada lote de la cuota diaria gratuita o de tu saldo de crédito. Las cabeceras X-Quota-Used y X-Quota-Free-Remaining de cada respuesta te dicen exactamente en qué punto estás antes de enviar el siguiente lote.
Aplicar geocodificación inversa a una lista completa de esta forma convierte lo que antes era un bucle lento en una solicitud por lote, con la API haciendo el mismo trabajo por elemento en cualquier caso. Todos los detalles de solicitudes y respuestas están en la documentación de geocodificación inversa.