Two weeks ago I showed a screenshot of initial support for the MOTIS routing engine in KTrip in my FOSDEM 2024 report. Driven by the Transitous work this is meanwhile nearing completion and will ship with the 24.05 release.

Adding new KPublicTransport backends

KDE’s apps consuming public transport data such as KTrip or Itinerary are built on top of the KPublicTransport library, which abstracts various different protocols and services providing that data.

As questions about adding new backends have been coming up recently, I tried to improve documentation, developer convenience and common infrastructure while adding the MOTIS support:

  • KPublicTransport::AbstractBackend now has more documentation especially about the not so obvious aspects like paging support.
  • Backend configuration files can now also be loaded from $XDG_DATA_DIRS/org.kde.kpublictransport/networks rather than just from the compiled-in QRC data. By symlinking the corresponding source directory you can therefore see the effect of modifications without recompiling. This also allows having configurations for e.g. the public MOTIS demo instance or a local one in the repository without those being visible to users.
  • Improved the built-in infrastructure for paging through arrival query results, to the point where this now also works for subsequent arrivals with backends not having any native paging support.

MOTIS support

When it comes to MOTIS support, almost every feature of MOTIS’ API that is modelled in KPublicTransport has been implemented:

  • Station queries by name or coordinate.
  • Arrival and departure queries for a given station, including paging in all combinations.
  • Journey searches between a specific station and/or a coordinate, with paging support.
  • When search to/from a coordinate, intermodal routing is used, supporting the following options:
    • Walking
    • Biking
    • Taking a car
    • Taking a car to an available parking space and then walking to the station
Screenshot of KTrip showing a multi-train journey through Switzerland with individual stops being slightly behind schedule.
KTrip showing a journey with realtime delay information, data provided by MOTIS.

A few things still remain to be done:

  • Intermodal routing using shared scooters/bikes etc.
  • Retrieving routing paths for intermodal journey sections.

And there’s a few more very interesting features in MOTIS that we’d like to support eventually but that are currently not yet represented in the KPublicTransport API:

  • “ontrip” journey queries, that is starting not at a fixed location but on a train or bus already, finding the best route to a destination given the current realtime situation (which can change along the way).
  • Retrieving the realtime status of parking spaces. While in Germany that is always synonymous with car parking, the excellent bike parking infrastructure in the Netherlands in some places apparently also has API for the amount of currently available parking spots.
  • Support for routing profiles for walking sections. That is things like walking speed or your willingness or ability to deal with steps/stairs, steep elevation, etc.

MOTIS improvements

One thing that made the work on the MOTIS support somewhat unique is that this is the first KPublicTransport backend for which I had a fully functional local server setup, and one where I could debug and modify things even.

This allowed identifying a nasty API issues and subsequently getting that fixed, fixing a bug in location queries and even adding a missing feature. Ie. finally working the way we are used to in the Free Software world.

The wishlist for MOTIS has been growing over the past weeks as well, so there’s more to do here. MOTIS has a very strong focus on the routing algorithms, and their performance and optimality guarantees (ie. the hard part), but only exposes the bare minimum of information not relevant for routing in its API. From a client and UX perspective we’d like to get all details that could possible be important for users from the GTFS or GBFS source data though.

According to MOTIS’ Github stats two out of its top 10 contributors are meanwhile from KDE, so we’ll probably get all that eventually :)

Outlook

All of this work is motivated by the ongoing effort to set up a MOTIS instance for a free and open public transport routing service, which is continuing at a rapid pace. If that succeeds we’d be able to bring public transport routing coverage also to some areas where our apps are currently useless.

As I’m writing this I’m on the way to the upcoming OSM Hack Weekend in Karlsruhe, where I hope to discuss some of the challenges we encountered with scaling up the OSM-based first/last mile routing in MOTIS. More on that hopefully next week then.