GTFS headsigns not matching those returned by real-time API

[samvermette]

For instance the GTFS shows "First Tennessee Bank" and "Market" as the 2 headsigns for route 4, whereas the API returns EASTGATE HAMILTON PL and DOWNTOWN.

I see that the trip_ids seem to match somehow so we might map real-time to GTFS using that, but ideally the headsigns would be consistent across the 2 data sources no?

[samvermette]

In addition the API used to return the Inbound/Outbound direction, but no longer does. Actually it's not even returning pdrtl anymore. Sent an email to CARTA and will report back.

[samvermette]

Nevermind the API issues.

After investigation, it seems like the GTFS feed doesn't actually contain trip headsigns. Instead you're assigning a different stop_headsign value at every stop along the trip. Is this intentional?

[junosuarez]

ideally the headsigns would be consistent across the 2 data sources no?

Yes, this is an ideal end state :) There are a variety of software systems in place from different vendors, and the effort to update data in the right place so it is correct everywhere is an ongoing effort. As a smaller transit agency, CARTA is trying to strike a balance between providing timely and accurate information in a format easy for developers to consume & build on top of and all of the other day to day tasks of keeping the buses running on time. :)

After investigation, it seems like the GTFS feed doesn't actually contain trip headsigns. Instead you're assigning a different stop_headsign value at every stop along the trip. Is this intentional?

Correct, that's the case currently. We're aware of it, but it's probably not ideal. There are no plans to change that in the near term, pending other data cleanup efforts.

[samvermette]

As a temporary workaround, would there be any way to include the direction_id in trips.txt?