Une adresse dans un centre-ville bien cartographié ne vous apprend presque rien sur la façon dont votre système gère une route rurale, une frontière contestée ou une requête près des pôles. Testez délibérément les cas difficiles.
Un résultat vide est une réponse normale et valide, pas une erreur, et votre code a besoin d'un chemin prévu pour le traiter.
Une adresse rurale, un lieu remarquable ou un nouveau lotissement sans numéro attribué se géocode quand même correctement, simplement avec une précision plus grossière qu'une adresse complète.
Près des pôles, les méridiens convergent vers un point unique et les fuseaux horaires perdent presque tout leur sens. Les logiciels de localisation conçus sur des hypothèses ordinaires ont tendance à s'y comporter étrangement.
Deux points séparés par une courte distance peuvent se trouver à des dates différentes du calendrier, uniquement en raison du tracé de la ligne de changement de date entre eux.
De temps à autre, une seconde supplémentaire est insérée dans l'UTC pour le maintenir aligné sur la rotation réelle de la Terre. Presque aucune application n'a besoin de s'en préoccuper directement.
Une coordonnée située à quelques mètres d'une frontière peut, en géocodage inverse, être rattachée à l'un ou l'autre pays selon la façon exacte dont la frontière est tracée dans les données. C'est un cas réellement difficile, pas un bug.
Une seule chaîne d'adresse peut contenir plusieurs éléments de sens distincts, et une même abréviation peut signifier des choses différentes selon les pays. L'analyser correctement est plus difficile qu'il n'y paraît.
Deux fois par an, une plage d'heures locales soit n'existe pas, soit existe deux fois. Un logiciel qui suppose que chaque heure est non ambiguë échouera précisément à ce moment-là.