Monitore o uso da sua chave antes de atingir um limite
Acompanhar seus cabeçalhos de cota ao longo do caminho mostra quando um limite está se aproximando, bem antes de uma requisição ser realmente rejeitada.
Faça a geocodificação reversa de uma lista de coordenadas sem escrever um loop
Se você tem uma tabela de pares de latitude e longitude e um script que chama a API uma vez por linha, está pagando pelas idas e vindas, e não pelas consultas em si. O endpoint de geocodificação reversa aceita um corpo POST em massa da mesma forma que o endpoint direto, resolvendo todos os pares em uma única chamada.
Enviando pares de coordenadas
Em vez de uma requisição GET por ponto, envie um array de objetos de coordenadas para /v1/reverse. Cada item retorna o seu próprio endereço, na ordem em que foi enviado.
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 que isso é melhor que um loop
Um loop que dispara uma requisição HTTP por coordenada adiciona sobrecarga de conexão a cada linha e torna mais difícil acompanhar a sua cota diária, já que você fica vendo cabeçalhos passarem em centenas de respostas separadas em vez de uma. Uma única chamada em massa continua cobrando uma requisição por item, então o custo total na sua cota é idêntico, mas você tem um único conjunto de cabeçalhos de cota para ler e um único lugar para capturar erros.
Lendo a resposta
Cada resultado do array corresponde à coordenada enviada na mesma posição. Se um ponto cair em algum lugar sem endereço próximo, como mar aberto ou uma grande área não mapeada, espere uma pontuação de confiança mais baixa ou um valor de precisão mais amplo, e não um erro, então verifique os dois campos antes de usar o endereço formatado em qualquer coisa voltada ao cliente.
Um segundo exemplo: combinando com dados de fuso horário
Um passo seguinte comum, depois de obter os endereços de uma lista de coordenadas, é descobrir que horas são em cada uma delas. Em vez de percorrer os resultados uma segunda vez, passe a mesma lista de coordenadas para /v1/timezone como uma requisição em massa própria. Você fica com dois arrays alinhados, endereços de /v1/reverse e identificadores de fuso horário de /v1/timezone, ambos na ordem original das linhas, a um custo de uma requisição por ponto por endpoint.
Um erro que vale a pena evitar
Não presuma que todas as coordenadas da sua tabela são válidas antes de enviá-las. Uma latitude fora de -90 a 90 ou uma longitude fora de -180 a 180, o que acontece com mais frequência do que deveria quando as colunas são trocadas em uma planilha, continua contando como requisição, mesmo sem poder retornar um resultado sensato. Verifique os intervalos no seu próprio código antes de enviar o lote, em vez de pagar por uma consulta que nunca teria sucesso.
Dimensionando os seus lotes
Não é preciso enviar uma tabela inteira do banco de dados em uma única requisição. Agrupe as coordenadas em lotes dimensionados de acordo com os limites de memória e de tempo do seu próprio script, e acompanhe quantas requisições cada lote consome da cota gratuita diária ou do seu saldo de crédito. Os cabeçalhos X-Quota-Used e X-Quota-Free-Remaining em cada resposta informam exatamente a sua situação antes de você enviar o próximo lote.
Fazer a geocodificação reversa de uma lista completa dessa forma transforma o que antes era um loop lento em uma requisição por lote, com a API fazendo o mesmo trabalho por item de qualquer maneira. Os detalhes completos de requisição e resposta estão na documentação de geocodificação reversa.