Using SIRI-ET and GTFS-RT TripUpdates in the same instance

[leonardehrenfried]

Right now it's not possible to run SIRI-ET and GTFS-RT TripUpdates in the same instance. This is not because there are fundamental incompatibilities between the protocols and down to OTP incurring some tech debt when SIRI was added.

This tech debt resulted in a lot of cyclic and otherwise strange dependencies.

In 2024 we undertook an effort to remove some of that tech tebt and the foundation was laid for running SIRI and GTFS-RT in parallel. Nevertheless, there was no final push because there wasn't anyone who needed this.

Situation right now

The dependencies between the core real-time classes is haphazard and historically grown. The SIRI and GTFS-RT have the responsibility to manage the snapshot and many dependencies are cyclic.

I tried to draw the current dependencies and it started to look very confusing so I focussed on the desired result instead.

I've investigated and have come up with the following class design.

Proposed class diagram

The core change are that the TimetableSnapshotManager, TransitLayerUpdater and TimetableSnapshot will be managed by Dagger and no longer by the updaters themselves. From this core principle we can derive the following class diagram:

Note that a single cyclic relationship between TimetableRepository and TransitLayer persists. It will be revisited later.

cc @fahrplaner @t2gran

[BredeD]

From a product point of view, this issue is relevant when going from GTFS/GTFS RT to Transmodel or using Transmodel based data with GTFS. Added it to the Roadmap Wish List