Existe uma categoria de erro de coordenadas que não tem nada a ver com a qualidade da geocodificação subjacente e tudo a ver com a forma como os números resultantes são armazenados, transmitidos e calculados depois. Um par de coordenadas perfeitamente preciso pode acumular um erro de arredondamento significativo apenas por ser representado em um tipo numérico com precisão insuficiente em algum ponto do seu caminho pelo seu sistema, e esse tipo de erro é totalmente evitável com um pouco de atenção deliberada.
Números de ponto flutuante de precisão simples, comumente chamados de float32, carregam cerca de sete dígitos decimais significativos de precisão. Para um valor de latitude ou longitude, que precisa de vários dígitos antes da vírgula decimal só para representar a parte inteira dos graus, sobram visivelmente menos dígitos de precisão real depois da vírgula do que o ponto flutuante de precisão dupla, comumente float64, ofereceria para o mesmo valor. Na prática, armazenar coordenadas como float32 em vez de float64 pode introduzir um erro de arredondamento da ordem de um metro ou mais, dependendo da latitude exata, totalmente independente e somado a quaisquer limitações de precisão que já existiam na correspondência original da geocodificação.
Esse tipo de erro é fácil de introduzir sem querer e fácil de não perceber, porque não parece um erro de nenhuma forma óbvia: a coordenada resultante continua sendo um número plausível e bem formado, apenas um que se desviou silenciosamente um pouco do valor original. Ele costuma entrar por uma coluna de banco de dados definida com precisão numérica insuficiente, por um formato de serialização de dados que usa por padrão um tipo numérico mais estreito do que o pretendido ou por um cálculo intermediário, como uma fórmula de distância ou uma transformação de coordenadas, feito em um tipo de precisão menor do que o usado no restante do pipeline.
A orientação prática é simples: use ponto flutuante de precisão dupla, ou um tipo decimal de ponto fixo equivalente com dígitos suficientes, para armazenar e calcular coordenadas em todo o seu sistema, de ponta a ponta, e não apenas no ponto em que elas são recebidas pela primeira vez. Verifique especificamente o esquema do seu banco de dados, já que uma coluna definida com um tipo mais estreito do que o pretendido é uma das fontes mais comuns e mais fáceis de ignorar desse exato problema, muitas vezes introduzida no início de um projeto e nunca revista depois que tudo funciona bem o bastante para passar nos testes iniciais. Verifique também qualquer camada de serialização ou de API entre sistemas, já que alguns formatos e bibliotecas usam precisão simples por padrão, a menos que sejam instruídos explicitamente do contrário, rebaixando a precisão silenciosamente justamente na fronteira onde você menos esperaria procurar.
As coordenadas retornadas pelos nossos endpoints de geocodificação direta e geocodificação reversa trazem valores decimais completos de precisão dupla. Vale a pena verificar diretamente se essa precisão é preservada ao longo do seu próprio pipeline de armazenamento e cálculo, em vez de presumir que ela sobrevive automaticamente a cada etapa.