Uma rua cujo nome tem um caractere acentuado, um trema ou um caractere de uma escrita não latina pode aparecer legitimamente em várias formas escritas diferentes, e todas podem estar corretas dependendo do contexto. Uma rua alemã com trema pode ser escrita com o trema intacto ou com a letra seguida de um "e" extra, como substituição padrão quando o caractere com trema não está disponível. Um nome escrito originalmente em uma escrita não latina pode ser transliterado para caracteres latinos de mais de uma forma aceita, já que a transliteração é um conjunto de convenções, e não uma única função determinística, e sistemas diferentes fazem escolhas razoáveis diferentes.
Isso cria um problema real de correspondência para a geocodificação. Se um usuário digita um endereço usando uma grafia válida e os dados subjacentes foram indexados com outra grafia igualmente válida, uma busca ingênua por correspondência exata falha, mesmo que as duas formas claramente se refiram à mesma rua real. Isso não é um erro de dados no sentido tradicional, as duas grafias estão corretas, mas produz o mesmo sintoma visível para o usuário: uma busca que não retorna nada quando claramente deveria ter retornado um resultado.
Uma boa correspondência de endereços lida com isso normalizando a entrada antes da comparação, removendo ou padronizando diacríticos, levando em conta as convenções de substituição conhecidas e tolerando as transliterações alternativas comuns de cada região, em vez de exigir uma correspondência exata, caractere por caractere, com a forma como os dados subjacentes armazenaram o nome. Este é, no fundo, um problema de correspondência aproximada (fuzzy matching), e afeta diretamente a pontuação confidence retornada para uma correspondência, já que um endereço resolvido por meio de uma variante com diacríticos ou de transliteração naturalmente tem uma confiança um pouco diferente de um endereço correspondido por uma string literal exata.
Vale a pena testar o tratamento de entrada de endereços especificamente com nomes que contêm diacríticos e com lugares onde a transliteração é comum, em vez de presumir que o seu conjunto de endereços de teste, se ele se apoia muito em endereços nacionais de uma única escrita, representa toda a variedade de entradas que os seus usuários realmente vão digitar. Um formulário que deforma ou rejeita silenciosamente um endereço internacional escrito corretamente é uma perda discreta, mas real, de tráfego aproveitável, e é um dos problemas de qualidade de dados mais fáceis de detectar cedo com um conjunto de testes deliberadamente variado.
Se você está criando um autocomplete ou um campo de entrada para endereços internacionais, teste-o diretamente com uma variedade de escritas e variantes com diacríticos usando o endpoint de preenchimento automático de endereços, em vez de presumir que os seus casos de teste nacionais atuais cobrem esse tipo de entrada.