Fluidtime shows you in this article how to design MaaS apps with GTFS. The report contains all necessary links to follow the procedure.

Introduction of GTFS and MaaS
Nowadays you and everyone you know are on the move more and more, using an ever-increasing number of transportation means and providers. Mobility as a Service links multiple Transportation Service Providers into one single offering, allowing end users to shape their mobility patterns based on their needs in an easy and flexible way. Fluidtime’s core product FluidHub does just that; it is a leading MaaS platform, providing you with a seamless travel experience tailor-made to your needs and region. The advantages are many: mobility becomes socially inclusive, affordable and environmentally friendly while transport and traffic planning are improved. The IT challenges for such a platform are manifold, we want to give you an example of integrating external sources to present arrival and departure times for public transport stops by using GTFS feeds.

What is GTFS?
General Transit Feed Specification (GTFS)defines a common format for public transportation schedules and associated geographic information. This de facto standard is employed by hundreds of transport agencies around the world and allows integration of public transit network information into your own applications.

Grafic: The GTFS Architecture applied at Fluidtime

The overall structure of GTFS is rather simple. A GTFS Feed provided by a transport agency is a zip file containing several CSV files. Each CSV file contains information about a part of the transport operator’s universe. Let’s start with an example, provided by the GTFS examples document. It describes the schedule of Route 1. This route is in service only during the winter. Two round-trips occur between downtown and the airport every weekday, also stopping at the railway station.

calendar.txt

routes.txt

trips.txt

stops.txt

stop_times.txt

If you’re curious what else GTFS can do (e.g. define fares), don’t be afraid to take a look at the GTFS reference document. In addition to static information, GTFS is also able to handle real-time information, described by the GTFS real-time reference. This includes deviations from a planned departure time or the current position of vehicles.

Fluidtime gtfsd – How we use GTFS for MaaS

One of the functions of our product is the display of departure and arrival times for a given station, we call it a monitor. Using GTFS we can provide this service for a variety of cities around the world. To allow for a scalable solution, we had the following requirements:

• Efficient serving of GTFS information for dozens of cities with modest hardware requirements
• A flexible architecture which allows easy implementation of internal requirements regarding transport network information
• Great performance

Existing solutions (like OneBusAway) load all information into memory. This provides good performance but is heavily constrained by the amount of memory needed. We had to find another way, and this is how gtfsd came to be. gtfsd (abbrev. for GTFS daemon) allows serving of GTFS information over a REST API, which is consumed by our MaaS platform technology FluidHub.

Grafic: The architecture of fluidtime products using GTFS

It consists of the following modules:

• The Static Importer is responsible for loading GTFS static information into a PostgreSQL database. This includes download, import and transformation of a given GTFS feed. It consists of some bash scripts and makes heavy use of the COPY command for fast loading.
• The Real-time Importer does the same for GTFS real-time information, the main difference being that it is called every 30 seconds to reflect the current real-time state. The importer consumes GTFS real-time feeds concurrently (using multiprocessing) in the protobuf format and imports them into the PostgreSQL database. It is written in Python.
• The widely known PostgreSQL database is the heart of gtfsd. Not only is all information stored in it, it also contains the business logic to allow presenting GTFS data tailored to our requirements. Data is shaped into the requested format using materialized views to be competitive in memory applications. Fragmentation is minimized through unlogged tables, and modularity uses features like schemas, views and stored procedures. The augmentation of static data with real-time data makes use of window functions.
• The Postgrest Server allows easy exposure of PostgreSQL data via a REST API. It eliminates the need for boilerplate code which would be needed for reading, transforming and presenting information as JSON.

Implementing gtfsd was a fun and rewarding experience. Achieving good performance proved to be the main challenge and required detailed studying of generated Explain Plans. Pev helped us get an insight into performance bugs (e.g. an index not being used) or forcing the planner to choose the right path using explicit joins. Besides that, we learned to love the indispensable DataGrip.

UX Design at Fluidtime: How we use GTFS for our MaaS solutions

The UX design team must now integrate the departure and arrival of the Fluidtime gtfsd into the FluidGo app (Android, iOS, Web), all in the spirit of delivering the best possible experience to our customers. Let’s have a quick look at our design process and detail how we went about creating our public transport monitor feature.

We began by looking at the existing solutions and finding ways to improve them; we gained a good understanding of the most sought-after features by comparing popular public transport apps from Vienna, Europe and the rest of the world alike.

We then created mockups with the information we want to present, namely a list of public transport stations, the departures originating at each station and finally detailed information about each departure. A screenflow was created by putting the mockups side by side and introducing flowchart elements such arrows and bubbles to illustrate the interactions taking place.

Graphic: Screenflow of the Fluidtime App – Fluidtime and GTFS

One of our biggest design challenges was the visualization of time schedules for stops and their corresponding live updates. Departure times are initially defined by a fixed schedule and then change due to real-world events, such as heavy traffic or construction work.

We decided to highlight real-time data with a consistent color scheme, marking on-time performance as green and delayed vehicles as red. We also convened on displaying live departure times in minutes until departure; if the data was not available then we chose to display the scheduled departure time.

Graphic: Real-time information and stop schedule at Fluidtime using GTFS

Cities generally choose easily recognizable colors for their public transport lines, making it easier for passengers to orient. The color codes are also available in the GTFS data provided, so we used them to draw our itineraries. Our fallback is to pick them from any available iconography whenever they’re not provided.

GTFS provides various opportunities for MaaS

This is the summary of how we developed our monitor by using GTFS, one of many features offered by our MaaS products. We’re constantly improving our MaaS solutions through developing new ideas and new functionality and also integrating feedback from our end users.