GTFS Static transit :: duplicate trip_id (trips.txt)

[Alexandre Martin]

Hello,


The description of the CSv trips.txt file leaves a doubt about the uniqueness of the trip_id field.
The trips.txt file makes the service_id, trip_id columns mandatory.
If a trip is reused by several services, is it allowed to generate the trips.txt file with duplicate trip_id?

The google documentation does not specify anything about this.

The validators block with a medium error.

Can you help me please?

Thank you.

Have a nice day,

Alexandre Martin

Translated with www.DeepL.com/Translator (free version)

[Brody Flannigan]

Hi Alexandre,

A trip_id must be unique, meaning there cannot be two rows in the CSV file with the same trip_id.

If the same trip operates on multiple services (For example, a northbound trip on route 1 at 8:30 AM runs on weekdays, saturdays and sundays), there are two ways to represent this:

1. Have multiple trips, one for each service, each with a unique trip_id

2. Have only one trip and create a calendar that specifically represents the operating days of this trip.

If you choose to go ahead with the second option and use the block_id field, be sure that the blocks are the same for the different service days.

Hope this helps!

--
You received this message because you are subscribed to the Google Groups "GTFS-realtime" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-realtim...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/dbeb8dd2-194d-42b6-98a5-b5db72782419n%40googlegroups.com.

[Alexandre Martin]

Thank you for your help and your quickly reply.

Unfortunately, the problem I am having is related to an AVL database.

The block_id field is already used by the driver duty information...
The AVL trips / journeys are factored and therefore duplicated in the theoretical GTFS export.

Strange that google does not mention in the documentation the rules of uniqueness of the fields.

I will try the first solution but I will lose client GTFS information.

Have a nice day,


Sincerely,

Alexandre Martin

[Brody Flannigan]

From my understanding, your CAD/AVL exports GTFS that is invalid because trips are duplicated (multiple trips with the same ID)

A solution could be to write a script that adds the service ID to the trip ID. For example, if a trip with ID TRIP1 operates on two services, SERVICE1 and SERVICE2, you could simply change the trip_ids to TRIP1_SERVICE1 and TRIP1_SERVICE2. Keep in mind though that if the CAD/AVL system is producing GTFS-RT, it will also need to be modified to add the service_id to the trip_id in GTFS-RT, in order for the RT to be valid.

Also, block_ids are not service-specific. There is an example of this in the reference document here. This might help you out a little bit.

If you have any questions don't hesitate to ask. (Je parle français aussi alors si vous souhaitez communiquer en français n'hésitez pas :))

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/a858d939-90d7-47a1-8fa9-77fae55e7b91n%40googlegroups.com.

[ពិសិដ្ឋ កូនសម្លាញ់របស់ខ្ញុំ]

នៅ​ថ្ងៃទី សុក្រ 17 មិថុនា 2022, 10:43 PM Brody Flannigan <Br...@flanny.ca> បាន​សរសេរ​ថា៖

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/CAJ%2BW7X9uDu%2BJyzgKeWJ4jt1QrKEmiNVcHbWtQp6dQrUZXAh_jw%40mail.gmail.com.

[Yuxuan Zheng]

Hi everyone,

I have a quick question about trip_id semantics in GTFS.

I noticed that within the same agency, some trips share the same route_id, service_id, and identical stop sequences with the same arrival/departure times, but have different trip_id values. This seems to happen when comparing different GTFS feed versions.

Is trip_id only required to be unique within a single feed, and not stable or unique across feed updates? In other words, is it expected that the same service pattern can receive a new trip_id in a later feed version?

Thanks for any clarification or references to the spec or best practices.

Best,

Yuxuan

[Todd Taylor]

This depends on how and when you export your feed. Do you only ever export current schedule information, do you include future schedule data in the same data set, and etc.

I have struggled with Ids and uniqueness. In my case , I had the requirement to output a GTFS schedule export for current, future, or current+future schedule data. In my case, I choose to append an incrementing schedule version to some of my GTFS entity ids, including trip_ids.  Current schedule data will have the current schedule version, and the future data will have the incremented schedule value. It guarantees trip_id is unique to a schedule. No matter how many times you export that same schedule, you'll get the same Ids. I found doing it this way yields less confusing data, helps you troubleshoot problems later, and it doesn't throw a wrench in the works down stream with your GTFS RT feed. 

For example, if someone submits the GTFS schedule with future schedule data early, I don't have to worry about GTFS RT validation issues with my live feed.

Plus, my current merge logic seems to appease the Mobility GTFS validator :)

[Yuxuan Zheng]

Thank you so much, Todd!!  This approach makes a lot of sense for versioned schedules and GTFS RT compatibility.

In my case, I’m appending all schedule versions into a single dataset and trying to retain unique trips across versions. Since versioning trip_id would treat the same underlying trip as different entries, I redefined a stable trip identifier based on route, timing, and other operational fields instead. This lets me deduplicate trips while keeping all service periods.

Thanks again for sharing your idea!!