Proposed Best Practice: always including trip_id in TripDescriptor for SCHEDULED trips
- Dominant language
- No language data
- Stars
- 1.1k
- Forks
- 225
- Avg merge
- 7d 17h
- Merged PRs (30d)
- 3
Description
## Context
This issue is part of an effort to bring one of the [outstanding issues we've identified](https://github.com/google/transit/issues/421) from the Best Practices repos.
## Issue
[In the Realtime spec](https://gtfs.org/realtime/reference/#message-tripdescriptor), producers can identify trips by either 1) having a trip_id that corresponds to the trip_id in GTFS Schedule, or 2) by including all of route_id, direction_id, start_date, and start_time instead.
However, based on conversation in [#gtfs-realtime](https://mobilitydata-io.slack.com/archives/C3D321CKB/p1681827091229099) ([you can join the Slack here](https://share.mobilitydata.org/slack)), option 1 (using trip_id) is easiest and most commonly used by consumers. Option 2 causes headaches and sometimes isn't supported by consumers at all. As a result, it would make sense to recommend that producers use trip_id in all cases.
## Proposed solution
Add a mention in the [TripDescriptor](https://gtfs.org/realtime/reference/#message-tripdescriptor) trip_id description that for SCHEDULED trips that are not frequency-based, the identification of the trip should be done via trip_id.
Tagging folks involved on slack @leonardehrenfried @e-lo @lauriemerrell @gcamp @doconnoronca @willcanderson
Contributor guide
Assessment
This issue has not been assessed yet.