Last weekend I joined the OSM Hack Weekend at Wikimedia Deutschland’s office in Berlin, mainly to work on a few Transitous-related topics.

A bunch of participants with laptops sitting around large tables.
OSM Hack Weekend at Wikimedia Deutschland (source)

Schedule data augmentation

One topic we wanted to move forward was how Transitous can augment the public transport data provided by operators and agencies, as having people from Transitous, OpenStreetMap and Wikidata together in one room is the ideal place for that.

Official public transport data often only covers the bare minimum, while Transitous and apps using it such as KDE’s Itinerary are continuously increasing the level of detail. A few examples:

  • Translated, transliterated or otherwise localized names for operators, stops, lines, etc.
  • Extended route types rather than just “train” or “bus”.
  • Line colors and logos.
  • Accessibility information about stops or vehicles.
  • Information whether a service requires a mandatory reservation or a surcharge.
  • Information whether taking along a bike is allowed, and whether that might require an extra ticket/surcharge.

Crowd-sourcing works for filling such gaps, and people are spending quite some effort on this, as seen e.g. in an 8.000 lines Lua import script patching line colors into the German public transport dataset. This isn’t really maintainable and scalable though.

That’s where OSM and Wikidata come in. Some of the extra data we want is already in there, and more importantly many of the objects we want to augment already exist in there (stops, operators/agencies, public transport lines, vehicle types). Collecting data in there would also make this more widely usable than just for Transitous.

Easier said than done though, as it’s not always obvious what should live in OSM and what should live in Wikidata. Public transport lines are particularly contentious, as they have a geospatial aspect but are difficult to maintain in OSM due to the way they are modeled, and likewise Wikidata wouldn’t want to see every bus stop in the world added just to model line stop sequences.

Another challenge is how to efficiently collect and match all this to the existing public transport data, as that generally doesn’t come with stable identifiers we can rely on. The approach currently explored is to generate a partial pseudo-GTFS feed from the OSM and Wikidata data, which MOTIS should be able to match and merge against the schedule data with little changes, using its existing matching and de-duplication infrastructure.

With another relatively small change to MOTIS we should also be able to retain and pass through Wikidata ids to clients, potentially enabling other interesting usecases there.

For more details also see the meeting notes in the Transitous wiki.

Mandatory reservations and surcharges

We also discussed how to model mandatory reservations and required surcharges in GTFS. MOTIS can also consider mandatory reservations during routing and avoid such services, which can be useful when you have a flat rate ticket for other services already. No matter whether operators provide this information themselves or whether it’s augmented from other sources, it needs to be properly represented in the data model though, which currently isn’t the case.

This tends to be somewhat abstract work, coming up with definitions of what a reservation and a surcharge are, and working through possible similarities, interactions, conflicts and ambiguities with existing elements of the GTFS data model such as the pick-up and drop-off constraints.

The best approach we could find would be an extension to the booking rules object, something currently mostly aimed at on-demand services but which should be flexible enough to also model e.g. services that require a reservation only during parts of their run, such as DB ICEs crossing into France.

Transitous usage policy

Something that unfortunately needs continuous attention is adapting and fine-tuning the Transitous Usage Policy. In recent weeks the main Transitous Matrix channel has been flooded with overly lengthy LLM-generated usage approval requests for LLM-generated single-use applications. These were not and are not the intended target audience of Transitous, but given their single-use nature most of those will never result in a relevant resource usage. The biggest problem they cause for now is making our main communication channel hard to use.

If the usage policy is actually read and understood we should hopefully see an improvement there now.

Upcoming conferences

We also did a bit of coordination and preparation for the larger events coming up in the second half of the conference season and which all have their CfP deadlines (very) soon:

Those are good opportunities to meet the Transitous team or the Open Transport community in general, same for the upcoming hack weekends listed on the Transitous website.