Mismatching stop_sequence in GTFS-static and RT

[Kona Farry]

Hi there, 

I've traced an issue in my app to stop_sequence values not matching in the static and RT feeds. This appears to be affecting the Red, Orange, and (all) Green lines; I'm not seeing it on the Blue line or any bus service. 

Essentially, the static feed is providing sequential stop_sequence values, e.g. 1, 2, 3 ... 10, while the ones in the GTFS-rt feeds are producing a different set of values, e.g. 1, 10, 20, 30 ... 120, 180, 190 ... 220. I'm seeing this in trip_update.stop_time_update and vehicle_position.current_stop_sequence. 

Here's an example with trip ID 51849905 (Red line to Braintree 22:30 today, Saturday). I've removed some fields for brevity: 

"stop_time_update": [
          {
            "stop_sequence": 1,
            "stop_id": "70061",
            "departure": {
              "time": 1660444260,
              "uncertainty": 360
            },
          },
          {
            "stop_sequence": 10,
            "stop_id": "70063",
            "departure": {
              "time": 1660444576,
              "uncertainty": 360
            },
          },
          {
            "stop_sequence": 20,
            "stop_id": "70065",
            "departure": {
              "time": 1660444697,
              "uncertainty": 360
            },
          },
          {
            "stop_sequence": 30,
            "stop_id": "70067",
            "arrival": {
              "time": 1660444808,
              "uncertainty": 360
            },
            "departure": {
              "time": 1660444874,
              "uncertainty": 360
            },
          },

You can see the produced values are 1, 10, 20, 30, but the expected values from the static feed are 1, 2, 3, 4. This results in a failure to match the entities to the corresponding static entries. 

Please let me know if there's any other information I can provide, I am happy to assist with resolving this to the extent I can. 

Thank you! 

---
Kona Farry (he/him)
Creator and Developer
Pantograph Transit Tracker

www.pantographapp.com

[Developer at MBTA]

Hi Kona,

Thanks for bringing this up. I can confirm that behavior, and I've made a ticket for us to look into it and try to address in our predictions software. Unfortunately, I think it would be a somewhat larger change on our end, given how we generate the TripUpdates, so we probably won't be getting to it in the very near term. You're right that Bus (and likely Commuter Rail) wouldn't have this issue because those TripUpdates are generated differently, based on the underlying GTFS static data.

One thing I'll note from the reference is that the `stop_sequence` is "Conditionally required" in StopTimeUpdates, in that either it or the `stop_id` must be present:

Must be the same as in stop_times.txt in the corresponding GTFS feed. Either stop_sequence or stop_id must be provided within a StopTimeUpdate - both fields cannot be empty. stop_sequence is required for trips that visit the same stop_id more than once (e.g., a loop) to disambiguate which stop the prediction is for.

We are clearly in violation of the spec, as you point out, because we choose to include `stop_sequence` and it does not match in some cases. However, we would be in line with the spec if we omitted the `stop_sequence` entirely, provided that the trip doesn't visit the same stop ID twice. I can confirm that for the routes in question there are no trips with that behavior. We can't actually omit those values, because we do use them internally (and only require that they're integers in increasing order, for our purposes), but perhaps you could ignore that field for subway TripUpdates, pretending we just supplied a `stop_id`, in a spec-compliant way?

Another thing to note is that our subway predictions often produce trips that are not in GTFS static at all, if a train is running and we can't match it to a scheduled trip. These are generally prefixed with "ADDED-" on the trip ID, but are something to watch out for as another case where the realtime trips won't match up with the GTFS trips.

Thanks for the report!

Best,

Gabe | Developer @ MBTA