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.

[davidr1234]

@eliasmbd Thank you for the expanation! We will follow up on this.

[leonardehrenfried]

Since GTFS has a highly pragmatic engineering culture, I think one of your challenges will be to establish a consensus in the community if compatibility with other standards like SIRI are a goal of GTFS.

My gut feeling is that the community will request you to put your proposal into an offical extension rather than the main standard but time will tell.

[miklcct]

Can we use original_trip_id, which is a Google extension, as the field name?

[skinkie]

@miklcct that could work, because it does not have to be unique.

[davidr1234]

@miklcct thank you for the suggestion.

1. We're not quite sure on how this statement is intended to be read (from https://developers.google.com/transit/gtfs/reference?hl=en): "If it's present in the trips.txt file, the original_trip_id value overrides the trip_id value for use by other systems. An example is realtime matching."
   -> does the global_trip_id by default override trip_id when present, or only when it is being used for "matching purposes"
   We will ask our consumers using G-Transit on how they interpreted this sentence to avoid later issues.

2. If everything's in the clear, we would later use this field for BOTH GTFS Static and RT - this documentation only refers to Static.

@skinkie what do you mean exactly?

[skinkie]

That for your usecase, you want to identify different trips using the same id. That will not work as trip_id because it has to be unique, original_trip_id, does not have to be unique.

[davidr1234]

A small update on this topic:

We have now talked to our consumers, who would directly benefit from the integration of the original_trip_id in GTFS-S and -RT. And at least one of them will integrate the changes.

Attached you'll find an adapted schedule (only the adapted trips.txt - significantly shortened due to space limitations) and realtime (protobuf, added .txt to be able to attach -> remove the .txt!).

However, basically, we have, as suggested here, transferred the "original_trip_id" from GTFS Transit to schedule and realtime.

gtfs-realtime.proto.txt
trips.txt

[eliasmbd]

Great to see this moving along @davidr1234. Consider opening a PR when you're ready as it can garner more visibility.