ODX - transfers / multiple vehicle trips

[antrim]

Current draft's definition of rider_trip.trip_id:

The trip_id field contains the ID of the trip associated with the unique rider, if this is known. If trip_id is empty, then the rider may have taken one of several trips, or several possible chains of trips, to travel between the origin and the destination.

"Origin-destination-transfer" (ODX) data is available from onboard passenger surveys, fare collection systems that require tap off, can be inferred in the case of "tap-on only" fare systems. It may also be available through mobile ticketing apps, though I am uncertain on this. It would be useful for GTFS-ride to be able to specify a rider trip across multiple vehicle trips.

One option:
Add a new file, ride_segment.txt (see issue #21) or rider_trip_segment.txt, which could associate rider trips to vehicle trips, i.e. with fields for rider_trip_id, trip_id (foreign key to trips.txt), boarding_stop_id, alighting_stop_id, etc.

[e-lo]

I have mixed feelings about including this as part of GTFS-RIDE, mainly because this data is coming from a very different source: person-based (fare media, surveys, phones) rather than vehicle-based (APCs). My initial position is that we should separate them in order to

1. separate different data from different origins,
2. simplify compare/contrasting with each other (b/c they will inevitably conflict with each other),
3. recognize that one is a sample (paths) while another is [usually] a population (APC)

Ideally it seems like there should be separate standards for data that deal with:

• Directly observable riders on vehicles (GTFS-RIDE)
• Directly observable paths of passengers (currently, there is dyno-path which could be cleaned up)
• OD Trip interchanges (akin to dyno-demand)

Then there would be some magic black box process that would smoosh all these together for various purposes.

[carletop]

There are two ways multiple vehicle trips would be depicted in GTFS-ride currently. One would be with temporally sequential entries of the same rider_id. The associated trip_ids could then be included with the multiple entries if desired. Analysis tools would then be able to query this information and recognize it as a single rider journey. To offer flexibility, an agency also has the option of depicting a multiple vehicle journey by including only origin and destination data in a single entry and leaving out the trip_ids, assuming they have the data and that representation fits their goals. We were envisioning that software analysis tools would be doing the job of calculating inferences and making connections from the GTFS-ride data. Does this add clarity to the discussion? @e-lo WIth the rider_trip.txt file entries aggregate APC data could not be used. That APC data would need to be in one of the other GTFS-ride files. The person-based sources are the potential inputs to this file.

[carletop]

To be clearer, in my previous reply I should have said "multiple vehicles journies" in the first line. @antrim I think your proposed option could be warranted in the future if users come to find that a place for that additional information is needed.

[alexjago]

My local agency, TransLink Queensland (yes, it's the same name as in Vancouver) presently publishes origin-destination data aggregated monthly by time of day and weekday/end. (It's a predominately smartcard-based fare system).

I've been told it's a bit of a safety issue to go more fine-grained - someone malicious could plausibly look at the data and determine that late every weeknight, stops X/Y/Z see one person each, alighting at specific times A/B/C.

I think that many agencies might refuse to implement rider_trip.txt for safety and privacy reasons. It confirms the perception that smartcard ticketing will be used to track people as they travel around the city.