🐛📄 – Add support for linked trips / passenger journeys

[chrisyamas]

Describe the problem

TIDES currently captures individual boarding and alighting events (passenger_events) and fare transactions (fare_transactions), but lacks a native way to represent a complete passenger journey spanning multiple trips or transfers.

This gap limits several analysis use cases identified by @JuanM2 (Juan Matute, UCLA Institute of Transportation Studies) in the context of regional integration performance measurement:

• Transfer activity volume
  • What proportion of trips involve transfers? Higher transfer tolerance may indicate better isochronic access. Transfers introduce uncertainty and risk, so passengers' willingness to transfer reflects system utility and reliability.
• Interagency transfer wait time
  • Combined with TIDES vehicle positioning or GTFS-RT, linked trip data could enable inference of actual wait times at transfer points. Passenger-weighted interagency transfer wait time could serve as a KPI for coordination performance.
• Linked vs. unlinked trip counts
  • Distinguishing between unlinked trips (boardings) and linked trips (complete journeys) for ridership analysis and reporting.

GTFS-Ride addresses this with a rider_id field in rider_trip.txt. TIDES has partial support via the optional token_id field in fare_transactions and fare_action values like Transfer entrance / Transfer exit, but these describe fare policy outcomes rather than journey-level linkage; and token_id requires inference logic and doesn't cover APC-only or cash-based data.

Possible Solutions

• Add optional journey_id to fare_transactions
  • link multiple transactions within a single passenger journey
• Add optional journey_id to passenger_events
  • link boarding/alighting events across trips
• Create new passenger_journeys table
  • summary table for complete journeys (origin, destination, transfers [observed or inferred])
• Formalize token_id usage with guidance
  • document how to infer journeys from token_id + temporal proximity

In at least one TIDES implementation, a journey_id field is already available from the fare system, and used internally to derive fare_action values, but is not currently surfaced in the final TIDES output. This suggests adding an optional journey_id field could be relatively low-friction for agencies with supporting fare systems.

For agencies relying primarily on APC data without fare linkage, journey inference would require ODX modeling or other inference approaches. The specification should accommodate both direct capture (where available) and inferred/modeled journey data.

Privacy considerations

• Any journey-level identifier introduces re-identification risk, particularly on low-frequency routes. Guidance should address minimum aggregation thresholds, temporal retention limits, and appropriate use cases for disaggregate journey data.

Additional context

• Target version: v2.1 as this enhancement is additive and non-breaking, suitable for post-v2.0 development.
• Related: GTFS-Ride rider_trip.txt specification
• Related: Proposed linked_transaction_id field for linking passenger_events ↔ fare_transactions (currently under consideration in issue 📄🚀 – Modify passenger_events table to accommodate fare gate and station-based events #241 )

[JuanM2]

Thank you for adding this issue. I think that weekly, monthly, or even annual aggregation of the following would solve some of the research and analysis needs I anticipate without re-identification risk.

• All boardings at a stop_id that were part of the 2nd or subsequent segment for a linked trip
• Boardings per agency at a stop_id that were part of the 2nd or subsequent segment for a linked trip
• Systemwide values for linked trips and unlinked trips (to produce a ratio)
• Route-level values for linked trips versus unlinked trips (to produce a ratio)

One practical consideration for why linked trips are important is if one considers the regional connector in Los Angeles. This project improved service by reducing some 3-segment trips to 2 or 1 segments taking less time, but also reduced the number of boardings / unlinked passenger trips. By tracking linked trips at the stop or route level, a planner or researcher could better understand the effects of service changes on tripmaking, which is distinct from boardings.

[mpaine-act]

With respect to a multi-leg, multi-modal passenger journey, consider one implementation to inform the review as defined in Open Trip Planner GTFS GraphQL API. Here, each leg may include an agency, a trip, boarding/alighting stops but some legs do not (bike, walk, ride-hail) and is entirely client-side data (no server records of followed journey.

Do I misunderstand the open question? I read this issue as mixing server recorded data (from AVL) with passenger pushed/recorded data (completed legs) which would likely need to be anonymized for PII reasons and would be of limited use for agencies to participate in.

[ithistle]

I agree with the use cases being valuable to agencies and other users.

However, I am not sure how one would use TIDES to calculate linked trips on a granular level other than using token_id which is already part of the spec. The token_id field would allow anyone to calculate linked trips or at least a ratio for trips where passengers used the same fare token (or some other consistent id that wasn't fare related, like a mobile device giving out pings).

If you don't have a robust fare system or if token_ids are not available the main way agencies calculate linked trips is through o/d surveys, or some kind of ride checking observations. I could see a summary table of these results being helpful as in @JuanM2 's comment above, so that one could estimate linked trips and transfers from, but that seems to overlap with some of the intent of GTFS-RIDE.