Add Optional vehicle_id Field to trips.txt

[MuckT]

Each trip should have only one vehicle. Allows transit agencies to identify the vehicle serving the trip.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please let us know the company's name.

[MuckT]

I signed it!

[googlebot]

CLAs look good, thanks!

[RachM]

In Sydney, we often have two buses (one directly behind the other) servicing a single trip at peak hour.

Also, from a consumer's point of view, what's the purpose of this field?

[barbeau]

Also, all agencies I've seen dynamically assign vehicles to trips every day, which is why this is a field in the GTFS-realtime spec:
https://developers.google.com/transit/gtfs-realtime/guides/vehicle-positions

I'm curious to know if there are any real world agencies that assign vehicle IDs ahead of time that wouldn't change for months so the GTFS data would remain accurate.

[MuckT]

The combination of two buses would have a single vehicle_id and if one of those buses was used individually for a trip, a different vehicle_id would be used. Alternatively a value for the vehicle_id could be omitted.

This field would be primarily used by transit providers. Some feeds, f-c23-metrokingcounty, appear to already use block_id to uniquely identify buses. Creating this field would help to eliminate the block_id being used as a vehicle identifier.

stop_times for trips with block_id 4449798 sorted by arrival_time

[RachM]

Can you please elaborate on 'eliminate the mess'? Maybe a concrete example of a problem that this field solves could help me understand?

[MuckT]

Updated my previous comment with an example of the problem and had moved the location of the field to the stop_times.txt. Then moved it back to the trips.txt

[RachM]

You will need to follow the process outlined at https://github.com/google/transit/blob/master/gtfs/CHANGES.md if you want this merged.

Note in particular that you need at least one GTFS producer and one GTFS consumer to implement the proposed change.

I still don't understand the value that this gives consumers (e.g. a transit app such as Google Maps). A concrete use case might help me understand this (e.g. how would you surface this information to users, or how would this information be used to calculate something that you can't calculate with the current spec). If you have a feed that is incorrectly using block_id, then that is seems like an error on the producer's side.

[jspetrak]

I am wondering how you plan to work with trains on the trip as there are not only single EMUs/DMUs used, but sets of EMUs/DMUs/traditional rail cars coupled into formation.

[antrim]

Quoting @MuckT:

"Creating this field would help to eliminate the from block_id being used as a vehicle identifier."

Is the purpose of this proposal to provide an alternative block_id field, one which would make it possible to indicate vehicle blocking even when a passenger cannot stay onboard for a subsequent vehicle trip?

Note earlier definition of trips.block_id:
"A block consists of two or more sequential trips made using the same vehicle, where a passenger can transfer from one trip to the next just by staying in the vehicle." (https://github.com/google/transit/blob/67bb79885b808632a38d644f63f67cc1c41cdd1b/gtfs/spec/en/reference.md)

Related discussion:

• transfer rules for routes and trips, and in-seat transfers #32 "transfer rules for routes and trips, and in-seat transfers"
• Blocks and service days - Clarify relationship of block_id & service_id #44 "Blocks and service days - Clarify relationship of block_id & service_id"

[MuckT]

Pull request #44 changed the definition of block_id's to exclude "in-seat transfers". It is now clear that the the block_id field is intended to represent “blocking” as related to vehicle service scheduling: this is what I sought to represent with the vehicle_id field. In light of this information I am abandoning this pull request.