feat(glides): add nextTripKey field to trips_updated.v1#20
Conversation
| - `revenue` (`"revenue"` | `"nonrevenue"`, optional): Whether the trip is in revenue service. | ||
| - `dropped` ([DroppedReason](#droppedreason) | false, optional): If present the trip was dropped for the provided reason. If set to `false`, the trip is not dropped (and restored if previously dropped). | ||
| - `scheduled` ([Scheduled](#scheduled) | null): For trips in Glides' schedule, this represents the scheduled data for the trip. It will always be present and won't change between subsequent updates to the same trip. For added trips, this will always be `null`. | ||
| - `nextTripKey` ([TripKey](#tripkey), optional): If present, this specifies the key of another trip that will happen immediately after this trip. This field MAY refer to a trip that has not been already seen in the event stream. This field is intended to communicate a change in the expected sequence of trips, such as the sequence implied by blocks in the schedule from HASTUS. Note that a single change indicating a sequential link between two trips may imply additional changes to other links. For example, consider an initial schedule containing sequences between trips A1 --> A2, and B1 --> B2. If Glides emits an update to A1 with `nextTripKey` referencing B2, this implies a break to the two initial links. Clients are expected to maintain a consistent schedule such that no two trips may link to the same "next" trip. Note also that this field does not support an "unset" value. If Glides wishes to restore the initial schedule after changing some links, it must explicitly emit the links to be restored. |
There was a problem hiding this comment.
suggestion: a couple of things:
- Reword this:
If present, this specifies the key of another trip that will happen immediately after this trip.
to something like
If present, this specifies the key of another trip that the vehicle performing this trip will perform immediately after.
- Re:
this implies a break to the two initial links.
can you be explicit and list out what links would be broken and which would be formed by processing the message?
There was a problem hiding this comment.
I'll take another pass at expanding it. Might break this out into a little subsection since it's getting a bit long to be an in-line property description?
|
I took the rewording suggestion and expanded the block break example. I also added a callout for the lack of a |
|
this looks good to me! sorry, I reviewed but forgot to leave an approval |
|
one note is that I think it might simplify this schema for glides to send |
How strongly do you feel about this? Even if it's redundant, my instinct is to stick with trip key to keep it consistent with the other fields. Also just to clarify, you're talking about for the next trip right? Not changing the existing |
|
(@rudiejd Forgot to tag you in my reply) |
|
My comment was not blocking, but for reference I think all of the references to |
3 participants
Pullout inspectors using Glides may decide to assign a vehicle to an upcoming trip in a way that breaks the vehicle's expected block of trips from the HASTUS schedule. Currently Glides can only convey this information via a
vehicle_trip_assignment.v1message, which cannot be emitted until the vehicle has finished turning around and is in position to begin the trip. Unfortunately this may be too late for RTR to make timely terminal predictions.The solution is to allow Glides to indicate the change in the block sequence ahead of time as part of a
trips_updated.v1message, by populating anextTripKeyfield. (This is somewhat analogous to theTSCH LNKmessages used by OCS to indicate block changes for heavy rail.)