Una dirección que se lee con total naturalidad en un país puede parecer completamente al revés, o simplemente incorrecta, si se estructura según la convención de otro país. El orden en que aparecen el número de casa, el nombre de la calle, la localidad, la región y el código postal es una cuestión de convención nacional, y a veces regional, no una plantilla universal fija, y dar por hecho que el orden de tu propio país es el natural o el predeterminado es uno de los errores más comunes y evitables al construir cualquier cosa que maneje direcciones internacionales.
Algunas convenciones colocan el número de casa antes del nombre de la calle y otras después. Algunas ponen el código postal antes del nombre de la ciudad en la misma línea, otras después, y algunas lo colocan en una línea completamente aparte. El orden relativo de ciudad, región y país también varía, y unos pocos países estructuran las direcciones de arriba abajo según la jerarquía administrativa, de una forma que resulta casi invertida en comparación con las convenciones que van de abajo arriba empezando por el edificio concreto.
Esto importa en dos partes muy distintas de un sistema. La gestión de la entrada, sobre todo en los campos de dirección de texto libre, tiene que tolerar de verdad las variaciones de formato en lugar de esperar una plantilla rígida, ya que los usuarios reales que escriben direcciones de su propio país las escribirán de forma natural en el orden habitual de ese país, no en el orden para el que se diseñó tu formulario. El formato de salida, es decir, mostrar al usuario una dirección devuelta, idealmente debería respetar la convención propia del país de destino en lugar de presentar siempre todas las direcciones con un único diseño fijo, con la casa primero o el código postal primero, sin importar dónde se encuentren realmente, ya que una dirección con formato local se lee con naturalidad, mientras que una con formato extranjero resulta claramente extraña, aunque todos los componentes subyacentes sean correctos.
La geocodificación en sí suele ser más resistente al orden de los componentes que un analizador ingenuo, sobre todo cuando trata la entrada como una cadena completa que se compara con datos de referencia conocidos en lugar de esperar los componentes en una secuencia estricta y predeterminada. Dicho esto, probar tu gestión de direcciones específicamente con ejemplos correctamente formateados de diversos países, y no solo con versiones reordenadas del formato de tu propio país, revelará carencias en tu propia lógica de validación y de visualización mucho antes de que los usuarios internacionales se topen con ellas directamente.
Si estás construyendo la entrada o la visualización de direcciones para un público internacional, vale la pena hacer pruebas deliberadas con unos cuantos países cuyas convenciones difieran claramente de las tuyas, en lugar de suponer que una sola plantilla sirve para todos. Nuestro endpoint de geocodificación directa está diseñado para tolerar estas variaciones en la propia entrada, pero conviene comprobar por separado tu propia validación de formularios y tu lógica de visualización de direcciones con esa misma variedad.
Una dirección en el centro de una ciudad bien cartografiada no te dice casi nada sobre cómo gestiona tu sistema una ruta rural, una frontera en disputa o una consulta cerca de los polos. Prueba los casos difíciles a propósito.
No todos los conjuntos de datos con información de ubicación de apariencia pública pueden usarse legalmente dentro de un producto de pago. Las condiciones de la licencia, y no la disponibilidad técnica, suelen marcar el límite real.
Cuando una consulta realmente no se puede resolver de forma fiable, no devolver nada es mejor respuesta que devolver una suposición disfrazada de hecho. Este es el razonamiento detrás de esa decisión.