Derive Headsigns when Schedule Relationship is ADDED

[Jason G]

Hello,

My team typically uses the trip ID in the v3 predictions endpoint to look up stop_headsign or trip_headsign fields in the static data. This works in most cases where a trip is in the schedule. However, when the scheduled relationship is ADDED, the trip does not exist in the static files, and the lookup fails.

Could anyone suggest a method for getting the headsign for this type of prediction? The direction_id and route is provided so I was thinking one option could be to combine these two pieces of info to derive a headsign based on route/direction lookup.

Thanks

Jason

[Developer at MBTA]

Hi Jason,

It sounds like you're getting real-time data from the V3 API, and static data from GTFS. We don't necessarily recommend this kind of cross-referencing, since both static and real-time data are published in both GTFS and the V3 API, so either way you can get all your data from one source and it will be internally consistent.

In this case, since GTFS-rt doesn't have good support for defining new trips that are not in static GTFS, you'll probably want to use the V3 API, where we are able to synthesize trips for ADDED predictions. For example, if using the /predictions endpoint, you can include the associated trips using include=trip (see documentation). This will return each prediction's trip in the same request, versus making a separate request to /trips.

Please let us know if you have any other questions about the structure of data in the API versus GTFS.

—Developer@MBTA

[Jason Goode]

Thanks for your reply! To clarify, my question centers around deriving/obtaining the proper headsign for a given prediction.

Is there a way to derive the headsign solely from the v3 API? Perhaps using direction and some other data?

As I understand it, headsigns are only explicitly written in static data. Specifically, in the stop_times.txt (stop_headsign) or trips.txt (trip_headsign). However, if the trip ID is "ADDED", no lookup is possible since the trip doesnt exist in static data.

Best

Jason

--
You received this message because you are subscribed to a topic in the Google Groups "MBTA Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/massdotdevelopers/iwSS7UlmIP8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to massdotdevelop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/massdotdevelopers/0cfe1704-b274-4dcc-9643-db98ea4e3481n%40googlegroups.com.

[Developer at MBTA]

Hi Jason,

Apologies if we weren't clear on this point: the V3 API incorporates all of our static data, which includes trips and their headsigns. It also dynamically generates trips for ADDED predictions, and presents these trips identically to the static trips, so you don't have to worry about the distinction. In general, and unlike in GTFS, "real-time" data is not segregated from "static" data in the API.

Here is a request which gets predictions for Commuter Rail departures at South Station, and the trips associated with those predictions, which includes their headsigns (limited to 1 record for the example's sake). If the prediction was ADDED, there would still be a trip and it would still have a headsign, although you would not find this trip in GTFS.

https://api-v3.mbta.com/predictions?page[limit]=1&include=trip&filter[direction_id]=0&filter[route_type]=2&filter[stop]=place-sstat

And the response (some data omitted):

{
  "data": [
    {
      "id": "prediction-CR-502663-709-NEC-2287-0",

      "type": "prediction",
      "attributes": {...},
      "relationships": {
        "trip": {
          "data": {
            "id": "CR-502663-709",
            "type": "trip"
          }
        },

        ...

      }
    }
  ],
  "included": [
    {

      "id": "CR-502663-709",
      "type": "trip",

      "attributes": {
        "bikes_allowed": 1,
        "block_id": "",
        "direction_id": 0,
        "headsign": "Walpole",
        "name": "709",
        "wheelchair_accessible": 1
      },

      ...

    }
  ],

  ...