Sinfonier Contest 2015: Sinfonier y Smart Cities

Las ciudades hoy en día generan una gran cantidad de información que puede resultar muy útil, algunos ejemplos son los niveles de contaminación del aire, que devuelven las sondas colocadas en diferentes puntos geográficos o la situación de nuestras carreteras, para saber si tenemos mucha afluencia de coches o ha ocurrido algún accidente. Estos datos ya están siendo usados, pero de manera independiente.

En la solución que he propuesto se basa en la ingesta de diferentes fuentes de información abiertas que están relacionadas de alguna manera y pueden relacionarse para sacar inferir resultados o recomendaciones que de otra manera serían imposibles.

¿De dónde podemos sacar esta información? Buscando en diferentes lugares de datos abiertos, me he encontrado con que algunas comunidades autónomas tienen su sitio web de open data:

• Documentación de la API de Zaragoza: http://www.zaragoza.es/docs-api/#/
• Portal de datos abiertos de Santander: http://datos.santander.es/
• Portal de datos abiertos de Barcelona: http://opendata.bcn.cat/opendata/es/
• Portal de datos abiertos de Madrid: http://datos.madrid.es/portal/site/egob

Cualquiera puede descargarse los datos que quiera dentro de un catálogo.
Inicialmente, iba a realizarlo a partir de los datos de la Comunidad de Madrid pero todo lo que encontré fueron datos muy separados en el tiempo, habitualmente con actualización anual o registro de datos de eventos pasados.

 

Por todo ello, elegí mi ciudad, Zaragoza, donde se desarrolló la siguiente API para los datos de los que disponían:

Vemos que tiene un catálogo (http://www.zaragoza.es/api/catalogo.json) bastante extenso, por lo que elegí diferentes fuentes de información y preparé los módulos en Sinfonier para poder extraer los datos que me interesaban:

Para recoger los datos, generé módulos spouts con los siguientes parámetros de entrada:
 

• Frecuency: Segundos que va a esperar el módulo en realizar de nuevo la petición, dando respuesta solo cuando aparezcan nuevos.
• Rows: Límite de valores que quiero que me devuelva el módulo.
• Start_date: Fecha inicial desde la cual se devolverán resultados en formato yyyy-mm-ddThh:mm:ssZ (UTC).
• Sort: Orden de las respuestas por parte del módulo (asc/desc).
• Q: Consulta mediante FIQL (http://tools.ietf.org/pdf/draft-nottingham-atompub-fiql-00.pdf) para permitir filtros y condiciones en las consultas utilizando una sintaxis con URIs amigables.

Más información en: https://www.zaragoza.es/ciudad/risp/ayuda-api.htm#PrametrosAPI. Estos módulos hacen la petición correspondiente con los parámetros configurados. Una vez tenemos estos valores, ¿cómo los podemos relacionar? Una opción es a partir del punto geográfico que puede aparecer en las respuestas, esto nos dará el punto de unión entre las diferentes fuentes de información.

Dentro de la topología, los valores que llegan se conectan con la entrada de otros, con los parámetros de latitud y longitud para así tener resultados solo en esos puntos.

Una vez tengo esa información necesito guardarla en algún lugar para después poder consumirla. En este caso, utilice una base de datos orientada a grafos, ya que me permite fácilmente tener esas relaciones almacenadas.
Utilicé como base de datos una Neo4j (http://neo4j.com/), la cual tiene ya módulos implementados que desarrollé tiempo atrás y permite la inserción de nodos y relaciones de manera única.

 

Una vez hecho esto, conecto las salidas de los módulos con los de Neo4j y ya tendría la topología terminada. Un ejemplo de esta conexión sería la siguiente:

 

Como resultado obtenemos lo siguiente:

 

En el grafo podremos realizar las consultas para lograr las recomendaciones. Por ejemplo cuando queramos saber si la oferta de una habitación de un hotel es una buena oferta sin basarnos solo en las opiniones de las habitaciones, sino viendo si existen relaciones en ese lugar como quejas, accidentes de tráfico, etc. y poder mejorar nuestra información.

Este es un ejemplo de una consulta que relaciona habitaciones de hotel con diversas quejas e incidentes.

 

Esta topología se podría ir nutriendo de nuevas fuentes de información y buscando nuevos puntos de conexión entre ellas para generar mejores recomendaciones. También se pueden añadir más comunidades autónomas para lograr una comparación entre comunidades.

 

Finalmente, quiero agradecer a Iñigo Serrano su colaboración a la hora de plantear la topología de este Sinfonier Contest.

 

Miguel Hernández Boza

Ganador de Sinfonier Contest 2015