Global trip id

[davidr1234]

Describe the problem

Hi,

Context: In Switzerland we've introduced the Swiss Journey ID (SJYID - documentaiton only in DE/FR/IT, sorry: https://www.xn--v-info-vxa.ch/de/datenmanagement/sid4pt-swiss-id-public-transport/swiss-journey-identification-sjyid).
It can be considered a "global" (day-long valid) trip identifier. One of the applications of this identifier is to allow mapping travel information among different mobility-data standards.

What we do: We will include the SJYID in our GTFS Schedule exports and intend to do the same for GTFS realtime.

What we realized: Discussions with other European public transport providers have shown that we may not be the only ones who need such a construct. Particularly, to ensure compatibility with other exchange formats.

What we suggest: Although this concept has apparently been explicitly excluded (see https://gtfs.org/realtime/reference/#message-tripdescriptor & screenshot), we suggest to re-visit this and consider including a new field "trip_global_id" that allows to combine/aggregate multiple trips.

Thank you for your input.

Use cases

Combining GTFS realtime data with NeTEx, HRDF, etc.

Proposed solution

Amend GTFS Schedule's trips.txt with a field "trip_global_id"
Amend GTFS realtime's TripDescriptor to include "trip_global_id" referencing the scheduled "trip_global_id"

Additional information

No response

[skinkie]

Why not just fill in trip_id with the contents of trip_global_id?

[eliasmbd]

@davidr1234 Thanks for bringing this up here. I am sure many contributors might be facing the same problem and could provide some insight. Also, thank you for posting your first issue on google/transit! Your contributions are always appreciated! 🚀

[davidr1234]

@davidr1234 Thanks for bringing this up here. I am sure many contributors might be facing the same problem and could provide some insight. Also, thank you for posting your first issue on google/transit! Your contributions are always appreciated! 🚀

@eliasmbd thank you, too.

Why not just fill in trip_id with the contents of trip_global_id?

@skinkie that wouldn't work with the trip_global_id being valid throughout a day (for us at least, maybe in other countries the time-frame varies).

[skinkie]

@davidr1234 do you mean that global id is something like XX:20240524:1 or that you can have multiple trips on 20240524, that have XX:1?

[davidr1234]

@skinkie
so the global_id as we suggest it represent mutliple trips (each with a different trip_id) that are variants of the same "basic trip" with one "unique" "global/basic trip id".

I drew an example for it. Below shows - from the Swiss point of view - the same (logical) train, which has always the same global id (SJYID), but two different trip_ids (NOTE: I did not increment the second trip_id, sorry, but it should be a different one!). The train deviates with regard to the stop_times and days of operation (the former usually inherently due to the latter). In Switzerland these (logical) trains are defined by the transport operators (to; 33 = BLS):

[leonardehrenfried]

If you included the global trip ID in GTFS Static as well as Realtime, what would it allow you to do? Isn't trip id and date unique enough? Or is it meant for cross-referencing GTFS Static with something like SIRI/VDV?

[davidr1234]

@leonardehrenfried your answer to your question is indeed the reason.

Example combinations could be GTFS static&SIRI (as you mention) or Some other static format&GTFS realtime

[leonardehrenfried]

If that is the case, then you might want to get the UK's BODS on board with the proposal. They include something called a "vehicle journey code" (very non-standard) in their GTFS feeds and my theory is that it serves the same purpose.

Check their feed from https://data.bus-data.dft.gov.uk/timetable/download/gtfs-file/all/ and look at trips.txt.

[davidr1234]

@leonardehrenfried thank you for the hint! We'll look into it and see if they'll support this suggestion.

[davidr1234]

Some weeks ago I wrote BODS and they intended to review the proposal. They do have a similar, but not quite the same setup as we suggest here. But as I understand this solution would still to some extend satisfy their needs.

@eliasmbd what is the procedure so that we can move the topic further forward?

[eliasmbd]

@eliasmbd what is the procedure so that we can move the topic further forward?

@davidr1234 Thanks for reaching out and wanting to bring this topic forward.

Here is the short form version of how to proceed assuming you will assume the role of advocate:

1. Create a Git Branch
2. Open a PR
3. Announce the PR on the GTFS Changes Google Groups
4. Host a discussion of a minimum duration of 7 days. Can be held on here or a Zoom. (MobilityData can assist you with this if you fin the necessity)
5. The changes must be implemented by at least one consumer and one producer before calling a vote. Proof of implementations must be demonstrated in a public facing manner.
6. Call a vote on GitHub. It lasts 14 days. There is a unanimous consensus yes with at least 3 votes requirement to pass. The advocate's vote doesn't count.
7. Voting results must be announced on GTFS Changes Google Groups
8. If passed the changes are merged.

Here is the full GTFS Spec amendment process

Let me know if there is anything else you may need from MobilityData. We are here to guide and help you.