FOSDEM 2024 and Open Public Transport Routing
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,
met 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.

Before 2023

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).

With OpenTripPlanner (OTP), Navitia and
MOTIS there are also three FOSS routing engine available.

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.

2023

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.


  
  
  
  Picture by OpenRail Association (source).


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

The hardest problem is solved, the thing has a name, Transitous,
and a project repository in the Github public-transport organization.
With concrete next steps in hand people head for lunch.

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.


  
  
  
  KTrip showing MOTIS search results across four countries and multiple different transport operators.


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.

Outlook

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.

If you are interested in collaborating on this, join the #opentransport Matrix channel
and the Transitous Github project!

  