GTFS trip_id spec/uniqueness

[T Sobota]

Our agency is migrating to a new transit vehicle CAD/AVL partner, which is changing our standard GTFS and GTFS-RT route_id and trip_id entities.

We historically had GTFS and GTFS-RT using unique/sequential trip_id (and route_id) entity values, each time a new service calendar period was published - which allowed "merging" of active and pending schedule period GTFS files into a combined fileset (active service period might have trip_id values 10001-20000, pending service period would pick up at 20001 thru 30000).

The new CAD/AVL GTFS and GTFS-RT system does not use sequential trip_id values from service calendar period to service calendar period.  When copying pending schedule period trip_id rows into the active schedule period's GTFS trips.txt file, validation fails due to repeated trip_id usages (a hypothetical trip_id value of 1-1-001, for hypothetical Route 1 Direction 1 Trip 001) is present in both the active and pending schedule period's data.

Question is that, while it would seem that logically, GTFS might effectively differentiate duplicated trip_id values using the associated service_id value and the calendar.txt and calendar_dates.txt files - on a date by date basis - I did want to confirm that active GTFS spec does not permit this (trip_id 1-1-001 on service_id 1 and calendar.txt service_id 1 dates 20240801 thru 20240817 cannot be differentiated from trip_id 1-1-001 on service_id 1 for calendar.txt service_id 1 dates 20240818 thru 20240901)

The concept of modifying the default GTFS trip_id values (for active, pending or both schedule periods), to create a merged file that eliminated duplicate trip_id values across these schedule periods would break correlation with the default GTFS-RT feed data still using the default (unmodified, duplicated) trip_id values.

Any feedback is welcomed.

Thank you

[Stefan de Konink]

Op 8/16/24 om 19:55 schreef T Sobota:
> Any feedback is welcomed.

Switch vendor.

--
Stefan

[Joey Reid]

Hi, we had similar experiences. The downside of the service-pick sequential numbering was that it was applied to our trips and routes, which meant that even routes had no stable identifier. Ultimately we decided to prepend the service_id to the internal trip_id. In your example that would be something like "1_1-1-001", for service_id 1 and trip_id 1-1-001. This works fine for trips and stop_times that use trip_id as the primary key, but it does mean that routes don't quite track the trips. For example, if you changed any attribute about a route (e.g., route_short_name) between one service period and another, that information wouldn't show up in your feed until the first service period left your feed. We consider this an acceptable compromise. You also need to make sure that the ids in the GTFS-realtime feed match those in your GTFS schedule. You could have something that prepends service_id to the trips in the realtime feed before the feed is made public, or you could pass the new trip_ids to your CAD/AVL system.

[Sergio Delgado Rodriguez]

Hi, Sergio from MobilityData here. Regarding your question on the use of duplicated trip_id and service_id in calendar.txt we can confirm that the specification currently does not allow duplicated service_ids in calendar.txt, as this field is specified as a unique ID, meaning that it would not be possible create two separate services running on different dates with the same service_id. 

As for using calendar_dates.txt, it is possible to define services on day by day basis with the same ID, but we can imagine that this could be a fairly impractical solution and a trip_id associated with a service_id would not differentiate from two service_ids if they share the same name. Hope this clarifies your question.