Niano Niano
16Abr/101

Malditas direcciones – Los países, sus regiones y la madre que los parió a todos.

Mi relación amor-odio con las direcciones seguro que es muy parecida a la de cualquier desarrollador detallista que haya tenido que lidiar con ellas en alguna aplicación.

Las personas humanas, entre las cuales me incluyo depende del día, estamos repartidos en 203 estados soberanos distintos a lo largo y ancho del planeta. Os desafío a que encontréis dos con exactamente el mismo sistema postal.

El fenómeno de etiquetar y catalogar los lugares donde las personas viven o ejercen su profesión está justificado exclusivamente por la necesidad de comunicarse de manera distribuida. Si no, para rato le gustaría a la gente que los demás supieran dónde vive uno.

"Tras cinco leguas, jinete y animal, sufren por igual" - Haiku ad hoc

Tras cinco leguas/ jinete y animal/ sufren por igual

Ante la imposibilidad que suponía que los correos (predecesores de los actuales carteros) supieran dónde vive cada persona en un contexto de ebullición humana a cascoporrillo por todo el globo, más de una mente pensante tuvo la misma idea de registrar los nombres de las calles y caminos y ponerlos en una lista.

Y los que no tuvieran nombre, pues se les ponía uno. Luego vinieron los números de calle, pisos, letras, manos y demás datos que ayudaron a especificar la ubicación del destinatario al que había que enviarle el edicto de embargo, la sentencia de muerte o la factura del móvil. Finalmente, con la llegada de mejoras tecnológicas y la mayor descentralización de los sistemas postales de cada país, se introdujeron los códigos postales para facilitar la gestión de cartas y paquetes pintiparados.

Este proceso genérico se ha ido produciendo en cada país, cada uno a su manera. A nadie le gustaba que llegara el Imperio Británico y les dijera cómo tenían que mandar las cartas. Es por ello por lo que, por ejemplo, no tenemos códigos postales en Hong Kong o por lo que en muchos países anglófonos usan dos líneas para la dirección y si les hablas de calle, número, piso, letra... se ponen ojipláticos, caen en barrena, entran en bucle y la palomita les hace *pop* en la cabeza. No sabrán de qué narices les estás hablando.

El territorio de las direcciones es el lejano oeste informático en pleno peregrinaje: un terreno basto, desigual e inhóspito, minado de dudas, peligros e inseguridades.

Desde el punto de vista del análisis de software y de la arquitectura de bases de datos, no hay estructura o modelo sencillo, elegante, completo, coherente y mantenible que represente toda la casuística posible. Si tenemos una estructura para cada país es completo pero no es coherente ni mantenible. Si optamos por una estructura con el mínimo común denominador será sencilla y elegante, pero estará muy lejos de ser completa (y seguramente solo se componga de una columna con un identificador entero autoincremental). Así ad-eternum.

Wait a moment! Seguro que alguien más listo que yo (y que tú) ya ha pensado cómo solucionar esto. Repite mil veces Design Patterns y luego usa un poco de Google antes de seguir. Resulta que hay esperanza, al menos para parte del problema.

Como el logo de la ISO está protegido con copyright, pongo uno de Dharma, que mola más

ISO: International Standards Organization

Lo que más les gusta hacer a los señores de la ISO es catalogar y codificar cosas. Si le echáis un ojo a las ISO-3166-1 e ISO-3166-2, veréis que en los últimos (casi) 40 años se han dedicado a mantener y codificar un listado de países y sus subdivisiones. Existen 3 tipos de codificaciones para los países: la ISO-3166-1 alpha 2, la ISO-3166-1 alpha3 y la ISO-3166-1 numeric. España, por ejemplo es "ES", "ESP" y 724 a la vez, depende del sabor de la ISO elijas.

Actualmente la ISO-3166-1 alpha 2 se distribuye gratuitamente en la web de la ISO. Sin embargo, la ISO-3166-2 solo se puede conseguir pasando por caja y os aseguro que es la que queréis conseguir para un sistema de direcciones. Al fin y al cabo, no queremos que nuestros usuarios escriban en los campos "localidad" o "provincia" lo que les dé la gana, porque terminaremos con una preciosa base de datos llena de cosas como: "sebiya", "cebilla", "seviya" y "sevilla".

Los de la ISO son unos suizos cachondos donde los haya porque, a parte de cobrarte por una información que debería ser pública y gratuita, los jodíos no se encargan de mandarte actualizaciones de la base de datos cuando introducen cambios, sino que te envía un boletín de cambios para que tú, si eso, los apliques en tu base de datos. Por no hablar del formato de la base de datos, que es Microsoft Access (eso es otro cantar).

Así que si decides pasar por caja (las dos ISOs cuestan 366 francos suizos), no solo tendrás que importar una base de datos Access, sino que además tendrás que estar al loro de los boletines de cambios para mantener tus datos al día. Ouch!

Por lo menos te dan los nombres traducidos al inglés y al francés...

Alternativa: Geonames.org

No se puede describir con palabras el esfuerzo monumental que supone este proyecto. Para empezar todo lo publicado en geonames.org tiene licencia Creative Commons Attribution 3.0 License. Se trata de una base de datos mucho más completa que las ISO mencionadas ya que incluye *todo tipo* de topónimos relevantes como accidentes geográficos, monumentos, etc. y, por si no fuera poco, ponen un API de consulta a disposición del que la quiera utilizar. Os animo a echar un buen vistazo.

La pega (y la ventaja) de geonames.org es que depende del esfuerzo colectivo de su red de colaboradores y la base de datos no avanza al mismo ritmo en todas sus áreas. Por ejemplo, aún no se han corregido los datos a nivel de subdivisiones territoriales en España del último boletín de la ISO. El proyecto necesita todos los colaboradores que pueda conseguir, entre los cuales, tenemos algunos muy relevantes como Luistxo de Tagzania.

Otra pega que viene con Geonames es que nos podemos encontrar códigos ISO junto con otros estándares como el FIPS o símplemente creados ad-hoc. Sencillamente, es más importante el geoposicionamiento que la aplicación de estos estándares, muchas veces incompletos para determinadas regiones.

Además, si decidimos importar la base de datos de geonames, tendremos que filtrar mucha paja para quedarnos solo con los lugares poblados y las divisiones administrativas. Supone curro, pero no es descabellado. De lo que no te libras es de estar pendiente de los cambios publicados en los boletines de las ISO (y, de paso, les mandas los cambios a geonames para que actualicen la info).

Lo que haría Chuck Norris

Realmente Chuck Norris no necesita buscar direcciones porque se las sabe todas de memoria, pero si no fuera así, lo que haría es recorrer la Wikipedia e importar la información en su base de datos y completarla con los boletines de la ISO u otras fuentes. Es frustrante ver que la información está ahí, al alcance de las manos, pero no tenerla en un formato exportable/explotable.

Lo que yo haría

Esta es la parte menos importante del artículo, ya que eres tú quien debe decidir cómo implementar direcciones en tu aplicación. En mi caso, me haría las siguientes preguntas:

  • ¿Es importante para mi aplicación normalizar estas cosas?
  • ¿Supone una ventaja normalizar estas cosas en mi aplicación?
  • En caso de responder Sí en las dos, ¿Mi aplicación debe (por cuestiones legales o por interactuar con otras) usar códigos standard?
  • En caso de responder Sí buscaría una manera de conseguir datos de la ISO
  • En caso de responder No en cualquiera de las preguntas, seguramente usaría la base de datos de geonames o sus APIs para aligerar mi aplicación

Cabos sueltos

Hasta ahora solo hemos hablado de países, regiones y localidades. Aun hay que resolver cómo manipular las demás partes que pueden conformar una dirección. Vista la envergadura de este artículo, dejo el apasionante mucho de las calles, números, códigos postales, bloques, y demás salsas para el siguiente de esta serie.

¡Nos vemos en el siguiente artículo de esta serie!

Comparte este post:
  • Print
  • del.icio.us
  • Facebook
Etiquetado con: , , 1 Comentario