Inconsistent ID names for deadhead trips

[dan-mccabe]

Consider the following row for a synthetic deadhead trip:

,trip_id,kWhs,miles,vehicle,route_id,service_id,block_id,shape_id,route_short_name,route_type,route_desc,agency_id,from_trip,to_trip,scenario,hvac_energy,gallons
2542,depot_to_6760013281020,,4.719598570859033,Transit_Bus_Diesel,from_depot_676000002631,67612,676000002631,from_depot_676000002631,from_depot_676000002631,3,Deadhead from depot to 6760013281020,,,,summer,1.7041160000002633,0.6013406749226743

The original GTFS trip IDs referenced in the trip, shape, and route names don't match: we have 6760013281020 some of the time and 676000002631 the rest. This example is from Chicago Transit Authority results but I suspect the same problem arises for other inputs.

[YiZoeHe]

Hi Dan,
I double checked and it’s actually intentional, and it doesn’t affect the energy predictions for deadhead trips. The trip_id for a deadhead trip is based on the first or last trip in a block. For example, "depot_to_6760013281020" means the it is the deadhead trip from the depot to the first trip with trip ID 6760013281020. The route_id and shape_id for deadhead trips are based on the block ID instead, since routes and shapes can be shared across multiple trips. 676000002631 in route_id "from_depot_676000002631" is the block ID of the generated deadhead trip.
If you think this is confusing, I can change route_ids and shape_ids to be the same as trip_ids, and I don't think the change will affect the energy prediction results.

[dan-mccabe]

@YiZoeHe Thanks for the explanation. I think it is okay to leave it as is for now. I had assumed these were two different trip IDs, not a trip ID and a block ID.

I think the most GTFS-like implementation for this would be to define deadhead routes and shapes as connecting stops (and depots). For example, if the first stop ID of this trip were stop_a, we might have

• trip_id: depot_to_6760013281020
• route_id: depot_to_stop_a
• shape_id: depot_to_stop_a

Then we would only have to define the route and shape a single time, instead of creating new ones for each block, since we can expect a lot of blocks to start at the same stop. But this is getting into the weeds a bit and I don't think we need to worry about it right now.

I'm going to keep this issue open so we keep it in mind for any future changes we might make, but we can put it on the back burner for now.

[YiZoeHe]

[like] He, Yi reacted to your message:

…

________________________________ From: Dan McCabe ***@***.***> Sent: Wednesday, January 21, 2026 7:57:18 PM To: NREL/routee-transit ***@***.***> Cc: He, Yi ***@***.***>; Mention ***@***.***> Subject: Re: [NREL/routee-transit] Inconsistent ID names for deadhead trips (Issue #50) You don't often get email from ***@***.*** Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> CAUTION: This email originated from outside of NREL. Do not click links or open attachments unless you recognize the sender and know the content is safe. [https://avatars.githubusercontent.com/u/25916826?s=20&v=4]dan-mccabe left a comment (NatLabRockies/routee-transit#50)<#50 (comment)> @YiZoeHe<https://github.com/YiZoeHe> Thanks for the explanation. I think it is okay to leave it as is for now. I had assumed these were two different trip IDs, not a trip ID and a block ID. I think the most GTFS-like implementation for this would be to define deadhead routes and shapes as connecting stops (and depots). For example, if the first stop ID of this trip were stop_a, we might have * trip_id: depot_to_6760013281020 * route_id: depot_to_stop_a * shape_id: depot_to_stop_a Then we would only have to define the route and shape a single time, instead of creating new ones for each block, since we can expect a lot of blocks to start at the same stop. But this is getting into the weeds a bit and I don't think we need to worry about it right now. I'm going to keep this issue open so we keep it in mind for any future changes we might make, but we can put it on the back burner for now. — Reply to this email directly, view it on GitHub<#50 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A3ARHDHA24WBZQT4EPVK7634H7KZ5AVCNFSM6AAAAACREE3T3SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOOBQHA3TMOJRGE>. You are receiving this because you were mentioned.Message ID: ***@***.***>