Eine Straße, deren Name ein Zeichen mit Akzent, einen Umlaut oder ein Zeichen aus einer nicht lateinischen Schrift enthält, kann berechtigterweise in mehreren verschiedenen Schreibweisen auftauchen, und je nach Kontext können alle korrekt sein. Eine deutsche Straße mit Umlaut kann mit dem Umlaut geschrieben werden oder mit dem Buchstaben gefolgt von einem zusätzlichen „e“ als übliche Ersetzung, wenn das Umlautzeichen nicht verfügbar ist. Ein Name, der ursprünglich in einer nicht lateinischen Schrift geschrieben wurde, kann auf mehr als eine anerkannte Weise in lateinische Buchstaben transliteriert werden, denn Transliteration ist eine Sammlung von Konventionen und keine einzelne deterministische Funktion, und verschiedene Systeme treffen unterschiedliche, jeweils vernünftige Entscheidungen.
Das erzeugt ein echtes Abgleichsproblem für die Geokodierung. Wenn ein Nutzer eine Adresse in einer gültigen Schreibweise eingibt und die zugrunde liegenden Daten mit einer anderen, ebenso gültigen Schreibweise indexiert wurden, scheitert eine naive Suche nach exakter Übereinstimmung, obwohl beide Formen eindeutig dieselbe reale Straße bezeichnen. Das ist kein Datenfehler im herkömmlichen Sinn, denn beide Schreibweisen sind korrekt, erzeugt für den Nutzer aber dasselbe Symptom wie einer: eine Suche, die nichts liefert, obwohl sie eindeutig ein Ergebnis hätte liefern müssen.
Ein guter Adressabgleich löst dies, indem er die Eingabe vor dem Vergleich normalisiert, diakritische Zeichen entfernt oder vereinheitlicht, bekannte Ersetzungskonventionen berücksichtigt und die üblichen alternativen Transliterationen einer Region toleriert, statt eine exakte Übereinstimmung Zeichen für Zeichen mit der Form zu verlangen, in der die zugrunde liegenden Daten den Namen zufällig gespeichert haben. Im Kern ist das ein Problem des unscharfen Abgleichs, und es wirkt sich direkt auf den für einen Treffer gelieferten confidence-Wert aus, da eine über eine Variante mit diakritischen Zeichen oder Transliteration aufgelöste Adresse vernünftigerweise eine etwas andere Konfidenz hat als eine, die über eine exakte wörtliche Zeichenkette gefunden wurde.
Es lohnt sich, Ihre eigene Verarbeitung von Adresseingaben gezielt mit Namen zu testen, die diakritische Zeichen enthalten, und mit Orten, an denen Transliteration üblich ist, statt anzunehmen, dass Ihr Satz an Testadressen, wenn er sich stark auf inländische Adressen in einer einzigen Schrift stützt, die ganze Bandbreite der Eingaben abbildet, die Ihre Nutzer tatsächlich tippen. Ein Formular, das eine korrekt geschriebene internationale Adresse stillschweigend verstümmelt oder ablehnt, bedeutet einen leisen, aber echten Verlust an nutzbarem Traffic, und es ist eines der Datenqualitätsprobleme, die sich mit einem bewusst vielfältigen Testsatz am leichtesten früh erkennen lassen.
Wenn Sie eine Autovervollständigung oder ein Eingabefeld für internationale Adressen bauen, testen Sie es direkt mit einer Reihe von Schriften und Varianten diakritischer Zeichen über den Endpunkt für Adress-Autovervollständigung, statt anzunehmen, dass Ihre bestehenden inländischen Testfälle diese Art von Eingaben abdecken.