remove run_events.trip_service_id from spec and trim examples #2
Conversation
|
|
||
| _Note that the `run_id` of 1 maps to the combination of `(service_id, trip_service_id)`, meaning other runs with the same `run_id` of `1` can be in effect at the same time provided they existin other combinations of `(service_id, trip_service_id)`._ |
There was a problem hiding this comment.
See comment below, but I think this is an important note to reiterate; perhaps this should be moved below, though?
The key thing I want to avoid is a consumer thinking the feed is broken because there are two versions of run_id = 1, each of which have different service_id values, though.
docs/spec/examples.md
Outdated
| ### Jobs of entirely nonrevenue operations | ||
|
|
||
| A special track inspection train is being operated on a particular day, supported by an extra crew position. | ||
|
|
||
| _Note: The deadhead trips themselves could be defined in their own new `service_id` even without definining corresponding run data in `run_events.txt` using the `calendar_supplement.txt` or `calendar_dates_supplement.txt` files._ | ||
|
|
||
| #### `trips_supplement.txt` | ||
|
|
||
| ```csv | ||
| route_id,service_id,trip_id,TODS_trip_type,direction_id | ||
| line1,inspection_train,inspection_line1_ob,deadhead,0 | ||
| line1,inspection_train,inspection_line1_ib,deadhead,1 | ||
| line1,inspection_train,inspection_line2_ob,deadhead,0 | ||
| line1,inspection_train,inspection_line2_ib,deadhead,1 | ||
| line1,inspection_train,inspection_line3_ob,deadhead,0 | ||
| line1,inspection_train,inspection_line3_ib,deadhead,1 | ||
| ``` | ||
|
|
||
| #### `stop_times_supplement.txt` | ||
|
|
||
| ```csv | ||
| trip_id,arrival_time,stop_id | ||
| inspection_line1_ob,downtown,08:00:00 | ||
| inspection_line1_ob,anytown,09:00:00 | ||
| inspection_line1_ib,anytown,09:15:00 | ||
| inspection_line1_ib,downtown,10:15:00 | ||
| inspection_line2_ob,downtown,11:00:00 | ||
| inspection_line2_ob,busyville,12:30:00 | ||
| inspection_line2_ib,busyville,13:00:00 | ||
| inspection_line2_ib,downtown,14:30:00 | ||
| inspection_line3_ob,downtown,15:00:00 | ||
| inspection_line3_ob,centerton,15:45:00 | ||
| inspection_line3_ib,centerton,16:00:00 | ||
| inspection_line3_ib,downtown,16:45:00 | ||
| ``` | ||
|
|
||
| #### `calendar_dates_supplement.txt` | ||
|
|
||
| ```csv | ||
| service_id,date,exception_type | ||
| inspection_train,20240901 |
There was a problem hiding this comment.
I do like the idea of including this as an example, because I think this is a big use case for the distinct TODS-specific modeling of non-public trips. That said, we could certainly cut this down to two trips of two stop_times each to simplify things. But open to cutting if the rest of the working group believes it to not be worthwhile.
|
As discussed in another channel: I added another note about the run id not being unique. It was already mentioned but not at all prominently. I don't want to add it to the example because it would distract from the complex situation that the example is trying to show. I've added back the nonrevenue job, simplified and moved outside of the mismatched crew/vehicle schedule section. |
jeffkessler-keolis
merged commit ada3f66
into
jeffkessler-keolis:separate_run_service_ids
trip_service_idfield.Here are the 5 examples that were there before:
trip_service_ididea.calendar_dates_supplement.txtif they're motivated to represent this in their schedules, so I didn't think it was important to keep.It may be easier to review this by looking at the diff to upstream/main, instead of the diff into your branch: diff
When this is merged, it should automatically show up in cal-itp#80