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.
Nem todo endereço tem número. Estradas rurais, alguns empreendimentos novos e pontos de referência conhecidos costumam ser citados sem um, e uma requisição de geocodificação construída esperando sempre um número vai interpretar mal como é um resultado válido nesses casos.
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"}
}
]
}Observe que aqui não há o campo house_number em components, e precision indica "street" em vez de "house". Ambos são esperados para um endereço que realmente não tem número, e não sinais de uma consulta que falhou ou ficou incompleta.
Trate precision como uma descrição de quão específica é a correspondência, e não como um indicador de erro. Uma precisão "house" significa que a correspondência foi resolvida para um prédio específico. Uma precisão "street" significa que ela foi resolvida para uma rua ou para um ponto ao longo dela, sem identificar um prédio exato, o que é exatamente o correto para um ponto de referência ou um endereço que realmente não tem número.
GET /v1/forward?q=Central Park, New York&limit=1Um espaço público com nome, como este, normalmente é resolvido com type definido como algo mais amplo do que "address" e com uma precisão que reflete uma área em vez de um único ponto, junto com um objeto components que pode incluir apenas uma cidade e uma região. É o mesmo padrão do exemplo da ponte: um resultado real e útil, descrito honestamente como cobrindo uma área em vez de um prédio específico, porque é a isso que a consulta de fato se referia.
Se a validação do seu formulário hoje exige que o campo house_number esteja presente para aceitar um endereço como completo, essa verificação vai rejeitar incorretamente endereços rurais e pontos de referência legítimos. Baseie os critérios de aceitação em valores de confidence e precision compatíveis com o que você realmente precisa, em vez de exigir que cada componente específico esteja preenchido.
Não trate um objeto components vazio, ou sem vários campos, como equivalente a uma requisição que falhou. Uma requisição que falhou volta com um status de erro e um código de erro, descritos na documentação de erros. Um resultado bem-sucedido com poucos componentes é um resultado diferente e totalmente normal, e confundir os dois no seu tratamento de erros fará com que endereços válidos sejam registrados e tratados como falhas.
Para um endereço sem número, mostrar o resultado formatado ao cliente para confirmação funciona melhor do que rejeitar o envio de imediato. Isso mantém um endereço real utilizável e ainda detecta, em outros pontos, entradas realmente ruins.
A geocodificação reversa de uma coordenada situada em campo aberto ou sobre a água também pode retornar uma precisão menos detalhada e menos componentes preenchidos do que uma coordenada situada sobre a área de um prédio específico. A documentação de geocodificação reversa descreve os mesmos valores de precisão a partir dessa direção.
Um endereço sem número custa a mesma requisição que qualquer outra consulta de geocodificação direta. A ausência de componentes não muda em nada a forma como a requisição é cobrada da sua cota diária ou do seu saldo de crédito.
Tratar isso corretamente é, em grande parte, uma questão de ler precision e confidence como foram pensados, em vez de supor que todo endereço válido precisa preencher todos os componentes. A documentação de geocodificação direta explica cada campo em detalhes.