-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate to GTFS-rt predictions and locations feeds #743
Conversation
Coverage of commit
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally looking good, just a few small comments below.
Also, we should remove the old url defaults in runtime.exs
and add the dev urls as defaults in .envrc.template
lib/predictions/predictions.ex
Outdated
@@ -10,11 +10,23 @@ defmodule Predictions.Predictions do | |||
predictions = | |||
feed_message["entity"] | |||
|> Enum.map(& &1["trip_update"]) | |||
|> Enum.filter( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: We could use Stream
here for efficiency, and/or combine this with the following reject
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah true. Might as well use the Stream
versions of most of the rest of these chained operations too. Any opposition to that?
lib/predictions/predictions.ex
Outdated
stops_away: stop_time_update["stops_away"], | ||
stopped?: not is_nil(vehicle_location) and vehicle_location.status == :stopped_at, | ||
vehicle_at_predicted_stop?: | ||
not is_nil(vehicle_location) and stop_time_update["stop_id"] == vehicle_location.stop_id, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we always look at these two values together, what do you think about combining them into a single flag like stopped_at_predicted_stop?
, which would be a drop-in replacement for the previous stops_away == 0
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh good call
test/engine/predictions_test.exs
Outdated
@@ -65,6 +65,8 @@ defmodule Engine.PredictionsTest do | |||
assert :ets.info(predictions_table)[:size] == 2 | |||
[{{"stop_to_remove", 0}, []}] = :ets.lookup(predictions_table, {"stop_to_remove", 0}) | |||
|
|||
:ets.lookup(predictions_table, {"stop_to_update", 0}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like it was left in accidentally.
nil -> [] | ||
stops -> [stops_away: stops, boarding_status: "Stopped #{stops} stop away"] | ||
end | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This still seems like a useful bit of abstraction over some common data patterns. If we just update it to use the new flag(s), we could probably avoid modifying some of these tests.
Coverage of commit
|
Coverage of commit
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See one suggestion, then looks good! Tested by running locally.
Co-authored-by: Brett Heath-Wlaz <[email protected]>
Coverage of commit
|
…bta/realtime_signs into pk/migrate-from-rtr-to-gtfs-rt
Coverage of commit
|
Coverage of commit
|
@panentheos When if you have a minute, could I get another pass at this one?
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See one comment, otherwise the changes look good.
lib/predictions/last_trip.ex
Outdated
"Green-D", | ||
"Green-E", | ||
"Mattapan" | ||
] and &1["trip"]["schedule_relationship"] != "CANCELED") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: We might want to split this route list into a helper, e.g. relevant_rail_route?
, since we intend for both code paths to use the same list.
Coverage of commit
|
Restoring the branch so we can deploy it to dev-green while we investigate what's going on with BRD predictions and passthrough announcements |
Summary of changes
Asana Ticket: Rearchitect RTS off of RTR
This change adjusts the predictions parsing logic to allow RTS to use the GTFS-rt feeds instead of the RTR feeds. The locations parsing logic doesn't need to be change because the GTFS-rt locations feed more closely mirrors the RTR locations feed.
The discrepancies in what fields are provided in the GTFS-rt feed compared to the RTR feed necessitated some slight logic changes in the main predictions flow. Most notably, the
stops_away
field is not in the GTFS-rt field, but we are able to use locations data to mimic howstops_away = 0
is determined as an alternative.Changes can be tested locally against the GTFS-rt production feeds by using the following URLs for the
TRIP_UPDATE_URL
andVEHICLE_POSITIONS_URL
env variables respectivelyhttps://cdn.mbta.com/realtime/TripUpdates_enhanced.json
https://cdn.mbta.com/realtime/VehiclePositions_enhanced.json
Before this is merged/deployed, we will want to put up a Terraform PR to change the values of the aforementioned env variables first. Once that is merged and applied, then we can re-deploy RTS with the new logic.