FOSDEM 2024 and Open Public Transport Routing
Last weekend I attended FOSDEM as part of KDE’s presence there, gave a talk about
semantic data extraction of travel-related emails,
old long-time friends, had many interesting discussions and the occasional waffle.
One topic however got slightly out of hand and ended up consuming most of my time.
Open Public Transport Routing
For road-based routing a few FOSS and Open Data services exist, OSM has some integrated on their website for example. We don’t have something like this for public transport though.
There we are stuck with proprietary services, run mostly by transport operators themselves or by companies like Google. Those have a number of issues:
- Borders. Transport operators tend to only cover the area they are serving, be it a municipality, a region or a country.
- Competition. Transport operators have no interested in showing services offered by their competitors.
- Access. Most of those services are meant for the corresponding websites or apps of the operators, access for 3rd parties (and even more so non-paying FOSS 3rd parties) is often restricted one way or the other.
- Privacy and data protection. Google is involved.
While much of this is understandable from an operator perspective, it’s not really satisfying from a user perspective. Therefore demand for an independently-run fully open public transport routing service has been building up since quite some time.
Roughly this would need three non-trivial ingredients:
- A FOSS routing engine.
- Freely available schedule data as well as realtime position/delay/disruption data.
- Someone to run that as a service.
So for context and dramatic effect here’s how things developed in chronological order.
With GTFS, NeTEx, SIRI, etc. standards for exchanging schedule and realtime data exist. Regulation mandating operators to publish such data also exists in several regions of the world (including the EU), compliance with that still has room for improvement though (especially in the EU).
Deployments for those also exist. OTP is used nation-wide in Finland and Norway, by a few municipalities in Germany (stadtnavi, bbnavi) and by community-run projects in the cities of Münster and Ulm. Being run not by transport operators, those show what becomes possible when your goal isn’t to sell your services but to help people to find the best way to get from A to B.
The Navitia team also runs an instance covering many areas all over the world. Routing between different coverage areas isn’t supported, but it’s often the only way to get any coverage at all, in particular outside of Europe. Many of the FOSS transport apps rely on this.
None of the FOSS engines scales well enough yet to be able to route across all of Europe though.
Navitia drops many coverage areas from their free service and SNCB discontinues their Hafas API, leaving the FOSS transport apps with several large gaps in the regions they can serve.
MOTIS is meanwhile said to have achieved acceptable performance for routing on an European-scale dataset on realistic hardware.
The year ends with various discussions on that topic at 37C3 showing a growing demand for a proper alternative, while at the same time technical blockers crumble.
February 3rd 14:00
It’s the first morning at FOSDEM. Mikolai Gütschow from Transportr presents in the Railway and Open Transport devroom, and towards the end of his talk suggests to create an open public transport routing service among the various parties in the growing FLOSS public transport ecosystem.
February 3rd 15:30
Following Mikolai’s talk a few interested people meet in the hallway discussing this subject. There is a sense of actually starting to look into possibly working towards implementing this eventually, gathering people that had shown interest in this, determining what would be needed in terms of infrastructure and approaching organizations that might potentially able and interested in hosting this.
And then things escalated a bit.
February 3rd 17:00
Approaching the end of day 1 of FOSDEM, a powerful server had been found. Retired from previously doing simulations in an university physics lab it comes with plenty of memory (which is important for this), and is hosted and available for free.
Moreover, Jonah had already been looking into setting up MOTIS on it and was getting the first results.
February 4th 11:00
The people interested in this (more by now) meet again in the hallway, to catch up on what had changed meanwhile and to discuss how to continue. Two topics are in focus in particular:
- Project setup, infrastructure and communication channels to work together.
- Designing a setup that allows for easy crowd-sourcing of the GTFS feed maintenance.
The last point is probably where most of the work has to be spend overall. FOSS routing engines exist, but they depend on correct input data, and that data is spread out into hundreds if not thousands of separate feeds of varying quality.
Keeping on top of each single one of those will likely involve manual work to some extend, and that is best done by someone local, understanding the local language and able to judge the correctness and completeness of the data. In some cases it might also involve working with the local public transport operator to resolve issues and/or to remind them of regulation requiring the publication of this data.
Luckily there is also quite some prior work around GTFS quality assurance and processing tools available which this can be built on top of.
February 4th 13:00
February 4th 14:30
While walking across FOSDEM to another unrelated meeting we get offered more servers to host this on. Just normal FOSDEM things.
February 4th 22:00
From on board of trains home the first code lands and the first merge requests are opened.
February 5th 07:30
People not having been at FOSDEM have gotten word of this and want to join.
February 5th and onwards
There is a continuous stream of work going on, including discussing GTFS feed metadata formats, identifying and fixing API issues in MOTIS, server setup and implementing MOTIS client support in KPublicTransport.
Initial experiments also show that further work in clients is needed to deal with the much larger variety of operators in the results, some of which might not be usable with an already existing ticket for example.
This is and remains an enormous task and there’s no guarantee of success. But if only a fraction of the momentum from the past weekend remains over the next weeks and months this might actually work out.