El OpenData de la Junta de Castilla y León es, como mínimo, muy mejorable

Definida por Wikipedia, la Junta de Castilla y León es, en nuestra España de comunidades, el órgano de administración y de gobierno de la comunidad autónoma de Castilla y León. Desde 1987 en manos de presidencia del Partido Popular, tiene, entre sus competencias: Sanidad, Universidades, Educación no universitaria, Agricultura, Empleo y Servicios Sociales, todas ellas transferidas del Estado central.

Se define (ya que estamos sentando las bases) como OpenData (datos abiertos en castellano, pero no queda tan bien) como aquella filosofía y práctica que persiguen que determinados tipos de datos estén disponibles para todo aquel que los solicite sin ningún tipo de restricciones.

open-data-junta-castilla-y-leon

Por supuesto, siempre ha habido OpenData en nuestra comunidad y en nuestro país. Bastaba con presentarte en la oficina correspondiente, rellenar la solicitud pertinente y esperar a que el funcionario encargado recuperase del archivo las copias solicitadas. Volver en un plazo de X días naturales, recoger la información pedida y hacer con ella lo que se creyese oportuno.

Pero bastante ha llovido desde aquellos días, y, aunque para determinada información sigue siendo necesario rellenar el formulario, Internet ha cambiado no solo la forma en la que nos comunicamos entre iguales, sino con nuestro gobierno y con las instituciones que lo representan.

Olvidémonos de trámites como permisos de construcción, citas con la Seguridad Social, etc, y vayamos directamente a lo que nos importa. El OpenData de la Junta de Castilla y León.

En un esfuerzo loable -todo hay que decirlo- la JCyL pone a disposición de todo aquel que lo desee, en un portal web bastante bien cuidado, un extenso catálogo de datos en distintos formatos, junto a su frecuencia de actualización. Entre los catálogos disponibles, se encuentran los siguientes (los que considero más interesantes o curiosos):

El problema es que tengo la horrible sensación de que de cada catálogo de datos se encarga un equipo distinto. Entiendo que algunos de ellos, como el de fotografía aérea, no estén disponibles más que en un servidor FTP ordenado por carpetas que no sigan, entre años, la misma nomenclatura (no sea que vayas a poder localizar la misma porción de terreno a lo largo de un periodo de tiempo fácilmente). No me entra en la cabeza, sin embargo, que algunos catálogos estén disponibles en XML y CSV pero no en JSON, que otros estén en JSON y CSV pero no XML, y que otros directamente utilicen únicamente un fichero PDF (que se ajusta a la definición de OpenData, pero con el que difícilmente se puede sacar partido a los datos de manera automática).

En un email que me reenvió un amigo (que es, en realidad, la causa de este post), se dice que los datos sobre cierto catálogo son volcados una vez al día de la correspondiente base de datos a los formatos en los que se oferta, para poder descargarlo. Y no sé si la causa es que los documentos están siendo generados por alguna herramienta automática terriblemente mal programada (quizá incluso usando directamente los nombres de las columnas de la base de datos como esquema), pero el uso de los mismos es prácticamente imposible sin un saneado previo en el lado del cliente. ¿OpenData? Sí. ¿UsableData? No tanto. Y en ese fallo es por donde se vierte, como por un desagüe, cualquier buena intención que pudiese tener la Junta al respecto.

Echemos un vistazo:

El documento empieza indicando que, a continuación, va a ir un documento. Menos mal. Seguidamente, la fecha de generación (bien), y después, una lista con los puntos de recarga, bajo el intuitivo nombre de list. A continuación, cada uno de los elementos (únicamente hay uno en el ejemplo, si queréis todos, arriba he dejado el enlace) va indicado bajo el nombre, repetido una y otra vez, de element. Y cada elemento element tiene un único atributo, bajo el nombre de attribute, que es, en realidad, una lista de atributos. Mamma mia. Veamos los atributos.

El primero de ellos tiene dos campos, name y valor. Mezclando inglés y castellano, porque por qué no. El nombre es Identificador y el valor es 1284335039174. Claro, no es como si en el propio JSON pudiesen haber hecho algo como “Identificador”:” 1284335039174″. No está pensado para eso. ¿O sí lo está? Da igual, sigamos, que queda miga.

El segundo atributo también tiene un name, que es NombreOrganismo. Pero este ya no tiene un valor, tiene un string. Porque en JSON es imposible inferir el tipo del campo si no nos lo indican, ¿cierto? Continuemos.

El par name-valor vuelve a repetirse, esta vez con listas vacías que tienen entre cero y ningún sentido. Por ejemplo, tenemos el atributo Direccion, que no tiene valor, pero seguidamente tenemos los atributos Calle y CodigoPostal, que sí tienen un valor (¿no forman una calle y un código postal parte de una dirección?). Sin embargo, el atributo Localidad_NombreLocalidad no lleva asociado ni un valor ni un string, sino un LocalidadPadre.

Avanzando, nos encontramos con otro atributo llamado Localidad_ID, al que veo dos problemas. El primero, que parece ser un campo de control interno. El segundo, que no respeta el CamelCase seguido hasta ahora, para pasarse a Snake_Case. Igual que sucede con Localidad_NombreLocalidad, o ya, directamente, los nombres con espacios como “Identificador Directorio Superior” o “Directorio Superior”. ¿Y qué sucede con SoloClasificar, que no tiene un valor? ¿Y qué hay de la Posicion, separando latitud y longitud por una almohadilla?

Pasar este JSON por algún deserializador estilo GSON conectado a Retrofit (por ejemplo) es prácticamente imposible. Crear una aplicación que ponga el OpenData al alcance del ciudadano promedio (recordemos que no todos los vecinos de Castilla y León son informáticos que se van a leer un JSON para saber dónde pueden recargar su coche) se convierte en una tarea titánica con nula recompensa. No anima a nadie a invertir su tiempo y conocimientos en ello, cuando con un JSON perfectamente formateado debería ser prácticamente inmediato para la mayoría de las plataformas mostrar esta información. La única razón por la que se publican aplicaciones en Play Store apoyadas en estas fuentes de datos sospecho que es porque se promueve (y casi se obliga) en las asignaturas de programación de los grados medios y superiores de la zona.

Pero no es únicamente problema del JSON. Termino este post con el mismo catálogo en XML.

Vaya, pues más de lo mismo.

Deja un comentario