Looking to see if anyone has found a way to describe the following in a GTFS static feed, or know if it would possible in the current spec without extensions. This describes a current real-world operating scenario for passengers.
A --------B ------- C
\
------ D
Trip X from A to C (stopping at B)
Trip Y from B to D
1) Trip X departs A as a two 2-car sets joined together (4 cars total as 2+2, passengers can not walk across the middle).
2) After trip X stops at B the rear half of the service decouples (with passengers still onboard doing an in-seat transfer) and starts the trip Y towards D
3) The front half of the original service now continues trip X towards C (with passengers still onboard continuing their original trip from A)
block_id can not manage this as trip Y does not validate as related to trip X given trip X is still running when trip Y starts.
The transfer_type option 4 included in
transfers.txt since
PR#303 appears to be designed for linking trips that includes uncoupled vehicles, but has similar limitations as block_id that it references arriving last stops and departing first stops.
Ideally we could find a way for GTFS consumers to be aware of in-seat transfer while maintaining this trip layout that reflects how the trips are managed for fleet operations and scheduling. Otherwise this could likely be made to work by manipulating the trips in GTFS to either have these as separate A to C and A to D trips (requiring the vehicle location and trip status data to be duplicated in GTFS-R up until B), or an A-B trip that terminates at B then allows for transfers into 2 new trips, but either of these solutions would require one-off data manipulation to take the "real-world" operational data and mangle it for the GTFS.