Status of MTA NYCT Subway GTFS-RT in OBA (Jan 2022)

[et...@transitscreen.com]

I am revisiting past issues we've encountered while trying to use MTA subway realtime feeds in conjunction with their scheduled feed. Relevant previous discussions with input from Kurt and Sheldon are here and here.

A brief summary of the issues:

1. trip_id matches between feeds are partial at best
2. If a scheduled trip is absent from the realtime feed, it should be interpreted as cancelled. Instead, OBA keeps serving the scheduled trip.
3. If a novel trip appears in the realtime feed, it should be interpreted as an additional trip. Instead, OBA ignores the novel trip.
   

Because of these issues, my organization currently does not integrate the two sources. If we want long-range planning we rely entirely on the scheduled feed, and if we want current arrivals/departures we rely entirely on the realtime feed.

We are about to embark on a project to better-architect our consumption and processing of the realtime feed. Before we do that I wanted to make sure we haven't missed any helpful developments in the past five years. I do find some references to special code OBA has used to handle MTA realtime feeds:

• http://developer.onebusaway.org/modules/onebusaway-gtfs-realtime-api/current/
• https://github.com/OneBusAway/onebusaway-gtfs-realtime-api/blob/4246e953b1c032becd04fa7d412fc27aa493e6b6/src/main/java/com/google/transit/realtime/GtfsRealtimeNYCT.java

But I can't tell if it's current or relevant to my summarized issues. I appreciate anyone with information chiming in so that we are sure we are spending time on the right problems. Thank you!

Ethan Pooley

Bonus topic: Although most of our use cases are adequately solved by one of the two feeds in isolation, one increasingly-important use case is not: routing. We are utilizing OpenTripPlanner, and its only approach (as far as we can tell) is to start with a scheduled feed and then overlay realtime updates on top of that. The MTA subway feed issues therefore leave us at a dead end for this purpose. I mention this here only because I know that OTP relies on OBA code for some of its capabilities. If anyone has cross-system knowledge that might be of use to us, we are all ears.

[Sean Barbeau]

Ethan,

I don't have any additional context on the MTA feeds and OBA, but FWIW OpenTripPlanner supports an interpretation of GTFS-Realtime ADDED trips:

* ADDED - https://github.com/google/transit/blob/master/gtfs-realtime/proto/gtfs-realtime.proto#L785

* OpenTripPlanner support - https://github.com/opentripplanner/OpenTripPlanner/blob/8b8a2d82cdd83e38bd028dff7b515ac7a607f09a/src/main/java/org/opentripplanner/updater/stoptime/TimetableSnapshotSource.java#L230

I don't know the exact behavior but I believe it's used in the Netherlands deployment. In theory I believe you could pass through #3 "novel trips" into OTP using this if you had a converter in between the MBTA feed and OTP.

Thinking more about this, the MTA subway feed (which I don't have any experience with) sounds more like a true frequency-based feed (exact_times=0 trips) in principle. See some discussion at https://groups.google.com/g/gtfs-realtime/c/ujeIp2UTnCs/m/DmhpatE-FQAJ for how these work in GTFS Realtime. tl;dr - real-time trips are materialized on-the-fly from the real-time feed and anything that's not in the real-time feed doesn't exist (i.e., there is no "scheduled" service), which sounds a lot like your description above.

OTP2 has work-in-progress support for true frequency-based trips, although I'm not sure if it includes real-time support:

https://github.com/opentripplanner/OpenTripPlanner/pull/3394

OTP1 supported static data for frequency-based (exact_times=0) trips, but not real-time data.

Sean

Sean Barbeau

Center for Urban Transportation Research

University of South Florida