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.
Normalize endereços digitados de forma bagunçada antes de geocodificá-los
Campos de endereço em texto livre acumulam uma grande variedade de hábitos de formatação: espaços extras, uso inconsistente de maiúsculas, abreviações escritas de formas diferentes e, de vez em quando, um caractere perdido colado de algum outro lugar. Nada disso necessariamente quebra uma requisição de geocodificação, mas fazer uma limpeza antes costuma melhorar a qualidade da correspondência.
O que limpar antes de enviar
Remova os espaços no início e no fim e reduza espaços repetidos a um só. Retire caracteres de controle e pontuação perdida que claramente não pertencem a um endereço. Deixe o conteúdo real do endereço como está, já que o endpoint de geocodificação direta foi feito para interpretar texto livre e não precisa que você o divida em campos separados de rua, cidade e código postal.
GET /v1/forward?q=221b baker st, london&limit=1O endpoint ainda assim geralmente resolve entradas com formatação solta como esta, já que foi construído para lidar com texto de endereço do mundo real, e não com um modelo rígido, mas uma string de entrada mais limpa reduz as chances de uma correspondência ambígua ou de baixa confiança em dados realmente bagunçados.
Um segundo exemplo: abreviações mantidas como estão
Uma consulta que usa abreviações comuns, como "St" para "Street" ou "Ave" para "Avenue", não precisa ser expandida antes do envio.
GET /v1/forward?q=500 5th Ave, New York&limit=1Expandir você mesmo cada abreviação antes de enviar a requisição é um trabalho extra que raramente muda o resultado, já que o endpoint já trata as abreviações padrão como parte da interpretação de um texto de endereço comum. Concentre o esforço de limpeza em entradas realmente defeituosas, como quebras de linha coladas ou artefatos de codificação, em vez de reescrever abreviações que nunca foram um problema.
Use o parâmetro countries para restringir os resultados
Se você já sabe em que país um endereço deve estar, por um endereço de cobrança cadastrado ou pelo foco regional de um site, informe-o com o parâmetro countries para reduzir correspondências ambíguas com lugares de nome parecido em outras partes do mundo.
GET /v1/forward?q=Springfield Main Street&countries=US&limit=3Um erro que vale a pena evitar
Limpar demais um endereço, removendo tudo o que parece incomum, pode eliminar informações de que o geocodificador realmente precisava. Um número de unidade ou de apartamento, a indicação de um andar ou o nome de um edifício junto ao endereço da rua são conteúdo significativo, e não ruído, mesmo que pareçam diferentes do resto do endereço. Limite a limpeza a espaços, codificação e caracteres claramente perdidos, e deixe como está qualquer coisa que possa plausivelmente fazer parte do endereço.
Verifique a confiança depois
A normalização reduz as correspondências ruins, mas não as elimina por completo. Sempre verifique o campo de confiança no resultado, em vez de presumir que um resultado retornado está automaticamente correto só porque a requisição foi bem-sucedida.
O custo da requisição continua o mesmo
Limpar a string de entrada antes de enviá-la não muda quantas requisições a consulta custa: continua sendo uma requisição por endereço. O que muda são as chances de que a única requisição enviada retorne algo útil, em vez de exigir uma segunda tentativa corrigida, que custaria uma segunda requisição.
Acertar a normalização desde o início significa menos consultas desperdiçadas e dados mais limpos nas etapas seguintes. Consulte a documentação de geocodificação direta para ver o conjunto completo de parâmetros suportados, incluindo countries e limit.