MaaS: Una aproximación GIS al problema de la Movilidad Urbana (II)

Hace unos meses, os hablamos sobre el concepto de MaaS (Movilidad como Servicio) y de cómo el GIS tenía la llave para adaptar y poner en marcha esta nueva tecnología. Hoy queremos profundizar sobre uno de nuestros últimos proyectos en el cual hemos modelado una red multimodal con todos los medios de transporte posibles para la Comunidad de Madrid.
El objetivo era crear una red navegable que permitiera al usuario calcular rutas en transporte público, eligiendo si quiere hacer uso de la ruta más rápida, la más económica o la más saludable y teniendo en cuenta todos los medios de transporte existentes, desde ir a pie hasta el coche/moto -Carsharing- o bicicleta -BiciMAD-, y por supuesto, los autobuses urbanos -EMT Madrid- e interurbanos -CRTM-, Metro y Cercanías -RENFE-.

 

Ante un reto de esta magnitud, el primer paso era crear la geometría de la malla de transporte. Para el coche, bicicleta y pie, pudimos contar con la cartografía navegable de HERE, que solo tuvimos que ajustar y parametrizar convenientemente. Para el resto de modos de transporte, obtuvimos la cartografía a través de fuentes públicas (EMT Madrid y Consorcio Regional de Transportes). Para dar conectividad a todos los transportes, tuvimos que crear el resto de líneas que simulan las paradas de autobús o los accesos y transbordos de las estaciones de metro y cercanías, poniendo especial atención a su geometría, pero también a los campos necesarios para el funcionamiento de la red y el cálculo de la ruta.

 

 

Para la generación de la red utilizamos la tecnología de ESRI, en concreto la extensión de Network Analyst que pone a nuestra disposición todo lo necesario para convertir lo que hasta este momento eran solo líneas y puntos, en una malla navegable. ArcGIS Server resultó ser el software ideal para el consumo de la red. Además de las extensiones que proporciona ESRI, ArcGIS Server ofrece la posibilidad de agregar extensiones propias desarrolladas por nosotros en .NET, para completar los requisitos necesarios de funcionalidad de la red.

 

 

 

Hubo que desarrollar una serie de evaluadores para configurar algunos atributos de la red. Por ejemplo, se creó un evaluador para tener en cuenta el tiempo de espera en los medios de transporte. La red puede calcular la ruta usando una impedancia de tiempo, pero esto solo afecta al transporte en movimiento. El evaluador, sin embargo, tiene en cuenta las frecuencias de paso de cada línea para hacer una estimación del tiempo final del recorrido más exacta.

Otro evaluador importante es el que calcula las rutas económicas usando como impedancia el precio de cada billete y devolviendo el coste real de la ruta.

 

Para completar el funcionamiento final de la red es necesario también consumir servicios externos, como el que nos indica la disponibilidad y la posición de las bicicletas de BiciMAD y los coches de carsharing de las diferentes compañías, o el servicio de HERE que ofrece la información de tráfico en tiempo real, aplicable a las rutas en coche.

Por último, todo el proceso de creación de la red se ha automatizado mediante un script de Python, de manera que podemos asegurar la integridad y actualización de la misma. Un cambio de frecuencia de una línea de Cercanías, el cierre de un acceso de Metro, o el cambio de trayecto de una línea de autobús, por poner algunos ejemplos, se traducen en la ejecución un proceso que crearía desde cero una nueva red totalmente funcional y con los cambios aplicados.

Una vez más el GIS nos proporciona las herramientas necesarias para facilitar la vida al usuario. Aunque por “detrás” tengamos un proceso de gran complejidad,  las personas que usen la aplicación final podrán ahorrar tiempo y dinero en sus trayectos por Madrid y hacerlo además de una forma ágil, sencilla e intuitiva.

 

Por Sergio Infanzón