Mismatched stop ids in GTFS vs V3 API

[Jeff Lopes]

Hello,

I was trying to figure out why my app isn't displaying realtime data for commuter rail  stops correctly and I noticed the stop ids in the GTFS data don't match the V3 API. For example: 

From stop_times.txt 

CR-595946-1610,16:45:00,16:45:00,NEC-2276-03,100,,0,0,0,,,

From /mbta/predictions?filter%5Broute%5D=CR-Needham&include=trip,vehicle,vehicle.trip&X-Api-Key=REDACTED

    {
      "attributes": {
        "arrival_time": "2023-08-19T16:43:00-04:00",
        "departure_time": "2023-08-19T16:43:00-04:00",
        "direction_id": 1,
        "schedule_relationship": null,
        "status": null,
        "stop_sequence": 100,
        "track": "3"
      },
      "id": "prediction-CR-595946-1610-NEC-2276-03-100",
      "relationships": {
        "route": {
          "data": {
            "id": "CR-Needham",
            "type": "route"
          }
        },
        "stop": {
          "data": {
            "id": "NEC-2276",
            "type": "stop"
          }
        },
        "trip": {
          "data": {
            "id": "CR-595946-1610",
            "type": "trip"
          }
        },
        "vehicle": {
          "data": {
            "id": "1813",
            "type": "vehicle"
          }
        }
      },
      "type": "prediction"
    },

You can see that they're the same trip id, but GTFS shows NEC-2276-03 as the stop id and the API shows NEC-2276. Is this expected?

Thanks,

Jeff

[Jeff Lopes]

Just checking in on this. Does anyone know if it's a data issue or if I'm using the GTFS data / API wrong? Thanks!

--
You received this message because you are subscribed to the Google Groups "MBTA Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to massdotdevelop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/massdotdevelopers/2c780606-2068-4462-a121-e3f6dfb0c7d0n%40googlegroups.com.

[Jeff @ Keolis]

Hi Jeff,

The behavior you're seeing is what's expected. In the example you've provided, the static GTFS schedules the trip to stop_id NEC-2276-03, which corresponds to Commuter Rail Track 3 at Back Bay Station.

This is the "normal" track at Back Bay, but given operational considerations, track assignments at our hub stations are highly subject to change. As such, the trip is not predicted to arrive on a particular track until the train has a specific assignment for that day's trip (typically when the train has departed South Station and is approaching Back Bay station).

The stop_id of NEC-2276 refers to Commuter Rail at Back Bay Station without a specific track assignment. The GTFS and GTFS-RT standards support providing a trip prediction to a sibling stop_id (that is, any stop_id sharing the same parent_station stop_id — place-bbsta in this example), which is also how a track change would be communicated (e.g. predicting the trip to NEC-2276-01 if the trip were changed to use Track 1).

In a regular scenario, you'd expect to see an assignment to (1) the scheduled track assignment, (2) the generic stop on the day-of when no track assignment is available, and (3) the stop_id of the specific track's stop at which it will arrive. As a more global rule, though, any sibling stop would be valid, which is how any sort of track change would be conveyed.

Best,

Jeff