La herramienta que necesitabas para encontrar el mejor piso posible… y que existe en Inglaterra

Illustreets es una herramienta web pensada para usuarios que buscan un piso para alquilar o comprar en Inglaterra, ayudándoles a encontrar el mejor vecindario. La aplicación aúna diferentes fuentes de datos abiertos proporcionados por el gobierno de Reino Unido, proporcionando una interfaz atractiva e intuitiva.

En este artículo haremos un sencillo ejercicio de análisis del modelo de datos e interacciones necesarias para comenzar a desarrollar una aplicación como Illustreets, utilizando CartoDB como herramienta de almacenamiento de datos y análisis de los mismos. En concreto, se utilizan:

   · La API SQL de CartoDB

   · La API javascript de CartoDB, CartoDB.js

Adicionalmente, veremos como los datos proporcionados por la BBVA Data API podrían servir para enriquecer aún más la aplicación.

Introducción: ¿cómo es la herramienta?

Lo primero que nos llama la atención es la elección hecha para aplicar los colores al mapa: vemos que los polígonos representando barrios concretos tienen colores entre el verde y el rojo, en función del nivel de vida (verde significa un nivel de vida más alto). Además, la interfaz es muy completa, pero no entorpece la exploración del mapa.

Al pasar el ratón por encima de cualquiera de los polígonos, en la barra lateral izquierda aparecen automáticamente una serie de estadísticas bastante completas, informándonos del nivel de vida del barrio, la tasa de criminalidad, etc. Y si pinchamos en cualquiera de los polígonos, en la parte inferior de la pantalla se nos despliega un informe lleno de datos útiles e interesantes para potenciales residentes en la zona.

Volviendo a la barra de la izquierda, no solo disponemos de estadísticas de los polígonos. También tenemos a nuestra disposición un menú que nos permite filtrar por precio y cálculo de rutas

Por último, la herramienta dispone de conexión con Google Street View, de manera que podemos darnos un “paseo virtual” por la zona, para ver el aspecto que tiene en realidad.

Componentes: explorador de propiedades de polígonos

El hecho de mostrar información cuando se pasa el ratón por encima de un polígono es algo realmente sencillo de obtener, mediante el uso de CartoDB.js. Se puede ver en este sencillo ejemplo.

Esta interacción básica nos sugiere que nuestro modelo de datos podría estar basado en una tabla conteniendo polígonos, y junto con cada polígono, una serie de estadísticas asociadas (se pueden entender mejor leyendo los informes que aparecen al pinchar en cualquiera de los polígonos, pero para nuestro ejemplo no es necesario):

   · Estándar de vida (valor entero 0 – 100)

   · Índice de criminalidad (valor entero 0 – 15)

   · Tasa de desempleo (un porcentaje)

Crear una tabla con estos campos usando CartoDB es también muy sencillo, como ya vimos en el anterior artículo sobre rutas arqueológicas en Córdoba.

Empezaríamos por entrar en nuestra cuenta de CartoDB (click aquí para conseguir una cuenta de CartoDB gratis), dirigirnos al dashboard, y añadir una nueva tabla, mediante el botón de create table, que tiene este aspecto

Veremos que tenemos varias opciones. Elegimos Empty table

Eso nos creará una tabla sin nombre, que posteriormente renombraremos a nuestra elección. Para nuestro ejemplo, podríamos usar el nombre tabla_poligonos

Posteriormente, podríamos añadir los campos necesario, usando el icono de Add column, abajo a la derecha

Nuestros campos serían de tipo number, y los podríamos llamar standard_of_living, crime_rate y unemployment_rate.

El campo geométrico para almacenar el polígono ya ha sido creado de manera automática, con el nombre the_geom

Para capturar el resto de estadísticas y asociarlas con nuestros polígonos, tendríamos diversas opciones. La pregunta básica que nos deberíamos hacer para elegir entre una u otra es:

¿Se va a ampliar con frecuencia el modelo de datos para incluir más grupos de edad, más tipos de inmuebles, etc?

Si la respuesta es SÍ, lo más conveniente sería crear tablas adicionales para capturar cada tipo de estadística, y enlazar estas tablas con la tabla de polígonos. Por ejemplo, crearíamos una tabla PRECIO_ALQUILER, con los siguientes campos:

   · polygon_id: almacenaría el campo cartodb_id de la tabla de polígonos. De esta forma, enlazaríamos ambas tablas.

   · num_habitaciones: entero de 1 a N

   · precio_alquiler

   · precio_compra

Hecho esto sabríamos, para cada polígono, cuál es el precio medio de alquiler y de compra de un inmueble con un determinado número de habitaciones. Añadir precios de alquiler/compra para inmuebles con un número cualquiera de habitaciones (6, 7, 8…) no implicaría cambiar el modelo de datos. Solo añadir más filas a esta tabla.

Por supuesto, la creación de la tabla usando el editor de CartoDB es tan sencillo como hemos visto para el caso anterior.

Si la respuesta es NO, una opción razonable puede ser ampliar nuestra tabla de polígonos para añadir columnas adicionales que capturen los siguientes requisitos por cada barrio:

   · Precio medio alquiler / venta en inmuebles de 1-5 habitaciones.

   · Rango de edad predominante (19-25, 26-34, etc)

En función del espacio que tengamos disponible, podemos seleccionar entre crear una columna por cada nuevo tipo de dato:

   · Precio alquiler piso 1 habitación

   · Precio compra piso 1 habitación

   · Precio alquiler piso 2 habitaciones

   · Precio compra piso 2 habitaciones

   · Porcentaje de vecinos en rango 19-25 años

   · Porcentaje de vecinoes en rango 26-34 años

   · Etc

Otra opción adicional podría ser utilizar el almacén hstore de PostgreSQL, pero es una solución algo más compleja, y no vamos a entrar en profundidad en este artículo.

No perdamos de vista las ventajas e inconvenientes de las 2 diferentes opciones que hemos valorado para crear nuestro modelo de datos basado en polígonos.

Si creamos una tabla adicional para capturar estadísticas asociadas a polígonos:

   · Ampliar el rango de nuestras estadísticas (ej: mostrar precios de pisos con más de 5 habitaciones, añadir rangos de edades…) no implican cambios en el modelo de datos. Solo añadir más filas a algunas tablas

   · Las consultas para obtener estadísticas implicarán cruzar la tabla de polígonos con las tablas de estadísticas. Si las tablas son muy grandes, las consultas pueden ser lentas

Si creamos una columna adicional en la tabla de polígonos por cada estadística a capturar:

   · Ampliar el rango de nuestras estadísticas implicaría cambios en el modelo de datos (añadir columnas nuevas a la tabla de polígonos y rellenar estas columnas)

   · Las consultas de obtención de estadísticas usarían una sola tabla, y no habría necesidad de cruces

Una vez completada nuestra tabla de polígonos (y tablas adicionales, si consideramos esa opción), crear una visualización por colores como la de Illustreets podría realizarse mediante el Wizard del editor, eligiendo la visualización por coropletas, y escogiendo la columna de nivel de vida como columna para aplicar color

Para finalizar el análisis del modelo de datos, mencionaremos otra funcionalidad muy útil que se nos proporciona de manera automática y sencilla, gracias al soporte completo de PostGIS que facilita CartoDB: cálculo de distancias a puntos de interés. Lo veremos en el siguiente apartado.

Componentes: motor de rutas

Cuando pasamos por encima de un polígono, entre las estadísticas que se nos muestran, vemos esto

Si además pinchamos en uno de los polígonos, entre la infromación que nos aparece en la perte inferior de la pantalla, vemos esto

Esta funcionalidad requiere que mantegamos en nuestra aplicación una tabla adicional de POIs (puntos de interés). O que los obtengamos en tiempo real de fuentes externas, como puede ser la API de Foursquare, como vimos en el artículo sobre rutas arqueológicas en Córdoba.

Si disponemos de una tabla con puntos de interés, la consulta para obtener las distancias a los polígonos que nos interesen pueden hacerse de manera sencilla en lenguaje SQL. Esta operación la puede realizar el código “backend” de nuestra aplicación (código que se ejecuta en nuestras máquinas antes de mandar la respuesta al navegador del cliente). Además, podemos elegir entre dos tipos de operaciones:

   · Obtener distancias de nuestros polígonos a los puntos de interés más cercanos. Obtendríamos el valor numérico. Interesante si queremos obtener una tabla con distancias en metros (o millas), como sucede en la segunda de nuestras capturas anteriores

   · Obtener únicamente los puntos de interés más cercanos, ordenados por distancia. Interesante si no nos interesa demasiado conocer el valor numérico de la distancia, pero queremos las ubicaciones de nuestros puntos para poder calcular tiempos de ruta entre ellos, simplemente

En el primer caso, la consulta SQL que ejecutaríamos sería como ésta

SELECT st_distance(pol.the_geom_webmercator, poi.the_geom_webmercator) as dist from tabla_poligonos pol, tabla_pois poi where pol.cartodb_id = 1 AND poi.type = ‘Hospital’ ORDER BY dist ASC

Como resultado, obtendríamos una lista de puntos de interés (hospitales, en nuestro caso), ordenados por distancia a un polígono específico (el polígono con id = 1, por ejemplo). Construir una tabla HTML a partir de ellos.

Destaquemos en esta query otro “truco oculto”: estamos usando the_geom_webmercator como campo para la función st_distance the PostGIS. Si echamos un vistazo a nuestra tabla de polígonos en el editor de CartoDB, no veremos este campo. Es un campo que se crea de manera interna para facilitar las visualizaciones, y para nuestro ejemplo es muy útil, porque almacena las geometrías en un formato que permite medir las distancias en metros, en lugar de grados. Para más información sobre este tema, se puede consultar este enlace

Si lo que queremos es una lista de pois ordenados por distancia a nuestro polígono, podemos ejecutar esta consulta:

select poi.the_geom, poi.name from pois poi, tabla_poligonos pol where poi.pol_id = pol.cartodb_id AND pol.cartodb_id = 17 ORDER BY poi.the_geom <-> pol.the_geom

Con esa consulta, obtendríamos directamente una lista de puntos de interés ordenados por distancia a un polígono concreto (otra vez el 17). Al tener los nombres y geometrías de los polígonos, podríamos usarlos como argumentos de entrada para un motor de cálculo de rutas que nos diera los tiempos estimados de ruta entre el centro de nuestro polígono y los pois devueltos. Es lo que nos interesaría para construir la funcionalidad de la barra lateral. Esta funcionalidad de cálculo de rutas en la parte del servidor podría implementarse con la extensión pg_routing de PostGIS. Su uso no está activado por defecto en CartoDB, de manera que habría que consultarlo con el equipo de soporte.

Destacar de la consulta el uso del operador “distancia” de PostGIS: <->. Fue implementado para la versión 2.0 de PostGIS, gracias a la financiación de CartoDB. Más información aquí.

¿Qué sucedería, no obstante, si no disponemos de tabla de puntos de interés?

En este caso, tendríamos que obtener los puntos de interés en tiempo real, en lugar de sacarlos de una tabla. Por tanto, no podríamos usar el lenguaje SQL. Tendríamos que realizar tanto los cálculos de distancia como los de tiempo de ruta usando otros medios.

Uno de esos posibles medios podría ser el uso de la API del proyecto OSRM. Otra opción sería delegar esta funcionalidad en el navegador del cliente, haciendo que la aplicación web se encargue del cálculo. Podría realizarlo a través de la Google Direction API.

Componentes: filtro de ubicaciones por precio

Otra de las funcionalidades de las que dispone Illustreets es el filtro de inmuebles por precio. Podemos acceder a él si pulsamos en el icono de la búsqueda avanzada, de la barra lateral izquierda (el segundo desde arriba)

El funcionamiento de un filtro de esta naturaleza es muy sencillo. Simplemente, activaría el lanzamiento de una consulta SQL parametrizada con los valores mínimo y máximo que elijamos. Algo parecido a esto

SELECT * FROM tabla_poligonos WHERE avg_price >= min AND avg_price <= max;

La vista se actualizaría convenientemente, para mostrarnos solo los polígonos que cumplieran esta restricción

Valor añadido: BBVA Data API

El uso de la BBVA Data API en una aplicación de esta naturaleza sería especialmente interesante. Entre las muchas opciones disponibles, podríamos destacar:

   · Añadir en cada polígono las categorías en las que existe mayor gasto. De esa forma, el potencial futuro residente podría saber si su barrio es un barrio comercial, y de qué naturaleza (gasto en moda, en comida, en ocio, etc). Podrían usarse los resultados devueltos por esta petición.

   · Añadir a cada distribución de edades por polígono, el gasto medio de ese rango en diferentes categorías. Así, podríamos saber si es un barrio en el que la gente de una determinada edad prefiere gastar en una determinada categoría. Interesante si quisiéramos añadir a una página como ésta precios de alquiler/compra de locales comerciales, por ejemplo. Podrían usarse los resultados devueltos por esta petición

   · Crear, para cada polígono, un modelo de patrón de consumo. Viendo a qué hora es más interesante realizar cierto tipo de compras. Podían usarse los resultados devueltos por esta petición.

Pueden consultarse el resto de peticiones de la API de BBVA en este enlace

En resumen, hemos visto como el uso de fuentes de datos abiertos, en conjunción con la capacidad de almacenamiento y análisis de CartoDB pueden resultar en productos que aportan gran valor añadido a tareas como la búsqueda de piso. Además, la BBVA Data API, podría resultar de enorme utilidad si quisiéramos aportar a un producto de esa naturaleza una fuente de información comercial y de gasto. Las posibilidades a nuestro alcance con estas tres potentes herramientas son casi ilimitadas.