Open BTollison opened 9 months ago
Would (3) be useful / could it satisfy the use case laid out here? @BTollison @skyqrose @jeffkessler-keolis
(3) would satisfy the use case here, and I believe could be valuable. The rail side often primarily matches trips to equipment in "cycles," which are often combinations of blocks in scheduling systems (i.e. the same as the block_group_id
proposed).
I'm fine adopting ods_block_group_id
as a standard ODS field for trips — the alternative being that we each use our preferred nomenclature e.g. "ods_cycle_id" on our end with the same functionality across producers.
This is a proposal to add block_group_id to trips.txt and deadheads.txt, and block_id to deadheads.txt. The intention to is to handle the need to group blocks together when you are using EV's. Traditionally, a block_id can cover either the entire string of trips for a specific vehicle over a day or model the peak work. It does not have to show what 1 vehicle will do for an entire day. This becomes important when trying to keep track of the amount of energy in a battery for a given vehicle.
block_id Add to deadheads.txt to keep trip of which block is part of a deadhead.
block_group_id A unique integer value per service_id, which helps group together all events that 1 physical vehicle does on a single service day.