feat: Pass along more enhanced JSON fields from RTR #252
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds two new fields to the
TripUpdates_enhanced.json
file, which RTR produces but currently Concentrate ignores. The fields are used by realtime signs. With the recent OL surge, there was a question about updating realtime-signs to use concentrate's output, in order to have access to CR data. They decided against it, for now, but it seemed like a good idea to me to update concentrate so that it would be possible in the future, if a situation like this came up again. The two fields are inStopTimeUpdate
and are:stops_away
- this is a field that says how many stations away the predicted train is from the stop the prediction is for.passthrough_time
- this isarrival_time || departure_time
forSKIPPED
stops, prior to those values being nullified by RTR. realtime-signs uses this to play the "next train does not take passengers, please stand back from the yellow line" message.I think both of them could arguably be implemented differently in realtime-signs such that these values aren't necessary but that's a larger lift, and in an app that our team doesn't maintain anymore. I didn't want to put that work on @PaulJKim , but I am open to potentially implementing it over there myself. It didn't seem so bad to me to have extra fields in our enhanced JSON here, so I went with the easier solution, but I could be convinced to take the other approach.