Los GTFS desde un punto de vista tecnológico

Los GTFS desde un punto de vista tecnológico

GTFS viene de las siglas en inglés General Transit Feed Specification, o en castellano Especificación General de Feeds de Transporte Público. El objetivo es establecer un formato común para los horarios de transporte público e información geográfica asociada a ellos.

Gracias a este estándar, las operadoras de transporte ofrecen a sus viajeras y viajeros información acerca de los viajes.

Un poco de historia

Cuentan que todo empezó en Google allá por el año 2005. Los empleados y las empleadas de esta compañía disponen de una política llamada “20% del tiempo”, lo que les permite dedicar el 20% del tiempo a leer todo tipo de cosas y a pensar en ideas y promover experimentos. Chris Harrelson deseaba incorporar información de tránsito en Google Maps cuando conoció a Tim y Bibiana McHugh, una pareja que trabaja en la compañía de transporte TriMet, de Portland, Oregon. En aquella época, los servicios de mapas más populares ofrecían indicaciones de viaje mientras se conducía, mientras que la información de tránsito en ciudades desconocidas era una utopía. Entonces, el de Google y la pareja de TriMet comenzaron a intercambiarse información, información de horarios en formato CSV.

De ahí nació Google Transit Trip Planner, siendo Portland la primera ciudad incluída en el proyecto con información de su sistema de metro. Pronto se incluyeron más ciudades de Estados Unidos y se fue extendiendo paulatinamente a lo largo de todo el mundo, a medida que su popularidad crecía.

Visión general de un feed GTFS

Un fichero GTFS es un archivo comprimido en formato ZIP que contiene varios archivos de texto en formato CSV. Habitualmente se conoce a éste como feed GTFS.

Cada archivo de texto que compone el feed modela un aspecto en especial de la información de tránsito, los cuales vamos a pasar a enumerar ahora mismo.

  • agency.txt

Obligatorio. Define una o varias empresas de transporte público que proporcionan los datos de este feed.

  • stops.txt

Obligatorio. Aquí se especifican las paradas a las que se da servicio.

  • routes.txt

Obligatorio. Se definen las rutas del transporte público. Una ruta es un conjunto de viajes que se muestra a los pasajeros y pasajeras como un solo servicio.

  • trips.txt

Obligatorio. Son los viajes para cada ruta. Un viaje es una secuencia de dos o más paradas que tienen lugar a una hora en especial.

  • stop_times.txt

Obligatorio. Dentro de un viaje, especifica el horario al que llega un vehículo a una parada y sale de la misma.

  • calendar.txt

Obligatorio. Define patrones de servicio en los que la empresa opera, como por ejemplo todos los días de la semana, solo fines de semana o de lunes a miércoles.

  • calendar_dates.txt

Opcional. Indica las excepciones de servicio de calendar.txt, aunque puede sustituirlo en caso de disponer de todas las fechas de servicio.

  • fare_attributes.txt

Opcional. Aquí es donde se definen las tarifas de las rutas.

  • fare_rules.txt

Opcional. Son las reglas de aplicación de la información sobre tarifas correspondiente a las rutas.

  • shapes.txt

Opcional. Aquí se definen las reglas para el trazado de las líneas en un mapa. Si no se definiera este archivo, las rutas estarían dibujadas como líneas rectas.

  • frequencies.txt

Opcional. Define el tiempo entre viajes para las rutas cuya frecuencia de servicio es variable.

  • transfers.txt

Opcional. En este fichero se especifican las reglas para establecer conexiones en los puntos de transbordo entre rutas.

  • feed_info.txt

Opcional. Aquí se incluye información adicional sobre el feed en sí, es decir, incluye información sobre el editor, la versión o el vencimiento del feed.

Generación de los feed

Habitualmente el origen de los datos se encuentra en un Sistema de Ayuda a la Explotación o SAE, al cual es necesario conectarse y documentarse para encontrar lo necesario para el feed. En estos casos, la tarea difícil radica en bucear entre las diferentes bases de datos en busca de la tabla que provea de lo necesario. En realidad este tipo de conexión no es otro que una base de datos donde elegir justamente lo necesario.

Sin embargo, el objetivo es siempre el mismo. Para empezar, se buscan los operadores que conforman el feed a construir, que suelen ser único. Además, se tratan de hallar los datos más estáticos, tales como sus paradas, rutas y calendarios. A partir de ahí, las tareas más difíciles las conforman el hecho de buscar los viajes para cada ruta y la generación de los tiempos por parada. Por norma general se evita mostrar las rutas en línea recta ofrecer el fichero shapes.txt, tal que las líneas que se dibujen en los mapas reflejen los trayectos realizados por las vías adecuadas (carreteras, vías de tren o metro…). Desafortunadamente, información como las tarifas, frecuencias o transbordos son raramente incluidas.

Lo deseable es que se provea de información fiel al estándar GTFS, de tal manera que su procesamiento sea ágil y no requiera de un largo tiempo de creación, dejando la información en repositorios como FTP, Amazon S3, etc.

Asimismo, dejando de lado los SAE y estos últimos, son muchos los orígenes de datos que se pueden tratar en Servicios Web, ya sean SOAP o Rest.

Tecnologías a nuestro servicio

Desde Ingartek apostamos y promovemos el uso del Software Libre. Partiendo del uso de tecnologías Java, nuestros desarrollos para el trato de feeds GTFS son construidos a partir del framework Spring Boot y de las herramientas creadas por Conveyal, OneBusAway u OpenTripPlanner, además de las propias que facilita Google.

Validación de feeds

Una vez generado un feed GTFS, es necesario comprobar que no contiene errores de ningún tipo. Para ello, Google creó FeedValidator, una herramienta que analiza feeds GTFS y genera un informe web donde muestra los errores y advertencias o recomendaciones.

Esta herramienta requiere conocimientos de empleo de terminales/consolas y línea de comandos, desde las cuales se hacen referencia a los feed GTFS y, con diferentes parámetros de personalización, se generan las validaciones.

Una vez realizada esa primera comprobación, es necesario subir los feed GTFS a la plataforma Partner Dash de Google. Ahí, se realiza una segunda y última validación, para después poner a disposición del público la información.

Conclusiones

En definitiva, el estándar GTFS requiere de conocimientos específicos para su implementación, ya sean técnicos en torno a las nuevas tecnologías o aquellos inherentes al transporte. Además, tiene que pasar por unos filtros muy estrictos que responden a estándares definidos por Google, lo que exige del dominio de una serie de herramientas.



¿Tienes un proyecto o idea? Contáctanos…

    Nombre (*)

    Empresa (*)

    (*) Acepto los términos y condiciones de uso sitio web

    (*) Campos necesarios

    Descárgate GRATIS nuestra guía para hacer una microsimulación de tráfico: