Transitous Hack Weekend July 2025

Last weekend I attended the Transitous Hack Weekend in Berlin. This was the first time we ran such an event for Transitous, and with quite a few more people attending than expected it most probably will not have been the last one either.

DELFI Family & Friends Day

Immediately prior to the Transitous Hack Weekend there was the 2nd DELFI “Family & Friends Day”, for which a number of participants had been in Berlin anyway. DELFI is the entity providing the aggregated national public transport static and realtime schedule data for Germany, which is important input for Transitous.

Extent and quality of that data have room for improvement, so having many members of the community there to lobby for changes helps. And while there’s certainly awareness and willingness among the people doing the work, the complex processes and structures with many different public and private stakeholders don’t exactly yield great agility.

Transitous Hack Weekend

For the Transitous Hack Weekend Wikimedia Deutschland had kindly allowed us to use their WikiBär venue. Special thanks also to Jannis, Theo and Felix for cooking for the entire group during the weekend, which not only kept us all well fed but also made the event particularly efficient and allowed us to cover a wide range of topics in the short time, as you can see below.

Topics

Legal setup

Transitous isn’t attached to any legal entity so far, which is a challenge when it comes to handling money, signing contracts or providing official data protection contacts. Eventually this needs to change.

Setting up our own foundation is of course an option, but that implies (duplicated) work and continuous cost that similar organizations have already covered. Therefore our preferred approach would be to attach Transitous to an existing likeminded foundation.

Usage policy

Transitous so far had no official rules on who can use it, and how. As long as it was primarily used by FOSS applications that wasn’t much of a problem, as that’s exactly what it is intended for. And even better, most of those were even actively contributing to Transitous in some form.

However we recently also got requests from non-FOSS and/or commercial users, which is not what Transitous is intended for. This is now being documented here.

For everyone else nothing should really change here, just please make sure you send proper client identification e.g. in a User-Agent header.

Data normalization and augmentation

There’s various reasons why we might want to modify the schedule data that goes into Transitous, it being incomplete, inconsistent ways of naming/labeling things between different data sources, or things just being outright wrong. Ideally all that gets resolved upstream, but that’s slow at best in most cases, and sometimes just not possible.

We were therefore discussing ideas on a declarative pattern matching/transformation rule system to define such modification in a way that remains maintainable when facing thousands of continuously changing datasets.

That still needs a bit more design work I think, but would allow to solve a number of current issues:

• Unify route/trip names. How bad this can get can currently be observed e.g. with long distance trains in Germany and Eurostar services.
• Normalize the mode of transport types across different sources. This would allow to fix Flixtrains being classified as regional train services for example.
• Augment agency/operator contact information, for use in integrated upstream issue reporting.
• Add or normalize line colors, and eventually add line, mode and operator logos.

Computing missing route shapes also fits into this, although that’s a bit special as it requires a much more elaborate computation than just modifying textual CSV cells.

Collaboration with other data aggregators

When Transitous started it was entirely unclear whether it would be able to ever scale beyond pure station-to-station public transport routing. We are way past that point meanwhile, with more and more things being added for full intermodal door-to-door routing. Many of those imply building similar dataset catalogs as we have for the public transport schedule data.

While we can do that, there’s often overlapping projects in those areas already, and our preferred solution would be to rather join forces. That is, collect and aggregate all input data there and consume it from that single source.

This includes:

• Availability of sharing vehicles (from GBFS feeds or converted from other sources). Looking at Citybikes for that.
• Elevator status data, which can be crucial for wheelchair routing. Looking at accessibility.cloud for that, the same source KDE Itinerary already uses.
• Availability of parking spaces, which then can be considered when routing with a bike or car. Looking at ParkAPI for that.
• Realtime road traffic data and dynamic roadsign data, which is useful for road routing. There seem to be some recent developments on this from CoMaps.

We also discovered a few data sets I had no idea where even available anywhere, like live positions of (free) taxis, which could allow new routing options. (Also, lots of Kegelrobben data, the use of which in a transportation context eludes me so far).

External communication

Transitous now has a Mastodon account! We’ll use that for service alerts, project updates and to share posts about related applications or events.

If you want to stay up to date on Transitous’ growing coverage and are up for a small Python coding task, a script to generate a list of coverage additions within the last week would help a lot with providing regular updates there.

We’d also like to have blog feed on the website, which would need to be set up but more importantly requires a few people committing to actually producing regular long-form content.

Documentation and onboarding

With a few people attending who weren’t neck-deep in Transitous or MOTIS code already, we had valuable fresh perspectives on the documentation and onboarding experience.

Both documentation and the usability and error handling of the tools in the import pipeline have benefited from this already, and there’s more improvements that yet have to be integrated.

Realtime data from vehicle positions

As realtime delay/disruption data still isn’t as widely available as basic schedule data, there’s high interest in computing that from vehicle positions. That’s essentially also what the “official” sources do, just that those can also take higher-level information about network operations, track closures, etc as well as human intervention/planning into account.

Vehicle position data tends to be more available, and can be obtained in various more or less creative ways:

• Some operators publish those as GTFS-RT feeds or at least in some proprietary form for displaying on their own website.
• Some systems send openly readable radio messages containing vehicle positions, such as AIS on ferries, ADS-B in aircraft as well as various radio protocols for trams and busses.
• Crowd-sourcing from within traveler apps such as Träwelling or Itinerary, which know which train you are on already anyway and have access to GPS.
• Dedicated driver apps for e.g. community-operated services.

Lots of opportunity for fun projects here.

And more…

Other topics people worked on included:

• Automating the collection of the hundreds of French GTFS feeds.
• Bringing new servers into operation.
• Improving the quality of the German national aggregated GTFS(-RT) feeds by generating them from NeTEx and Siri data ourselves.
• MOTIS and GTFS-RT diagnostic tooling.
• Better QA and monitoring.

And there’s also the meeting notes in the wiki.

More plans and ideas

With the foundation we meanwhile have with Transitous, there’s also ideas and wishes that are now coming into reach:

• Integrate elevation data for walk/bike/wheelchair routing.
• Support for ride sharing as an additional mode of transportation.
• Support “temporary POIs” such as events in geocoding.
• Showing interactive network line maps, as e.g. done by LOOM.
• Support for localized stop names and service alerts.
• Easily embeddable JS components for departure boards or fixed-destination routing for our events.

This is probably the most exciting part for me personally, I’m very happy to see people pushing beyond just a replacement for proprietary routing APIs :)

If you are interested in any of this, join the Transitous Matrix channel and consider joining the Open Transport Community Conference in October!