-
Notifications
You must be signed in to change notification settings - Fork 3
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
🧠 Implement "uncertainty adapter" within Concentrate #346
Conversation
…rmine uncertainty value
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.
question: is the parser the right place to be making a change to the data? how is this going to work in the future when we want to incorporate other sources of data into these uncertainty updates?
I'm also a little confused about why this particular change is happening in Concentrate, vs RTR. Since RTR is putting in the update_type
value, why isn't it also updating the uncertainty
values in the feed it puts out?
subsequent PRs which expose these values from concentrate will also remove the integer values so the atom/string values are the only things that will be passed from rtr and out of concentrate. I wanted to leave the parsing of int values at least temporarily so that we don't need to coordinate a double deploy of rtr and concentrate to deploy/rollback these changes |
@paulswartz to clarify. the example in the description is more about demoing the logic of using |
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.
@bfauble Thanks for this change! A couple questions:
- I'm a little confused about the implementation plan here. Why are we adding
update_type
to RTR only to convert it back into an opaque uncertainty value in Concentrate? - Do you think this would be better as a
GroupFilter
than a parser extension? That's what I was imagining, though seeing as the implementation plan here is also different from what I expected, maybe putting it in the parser makes sense.
Let's discuss at standup :)
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.
As discussed in Slack, this needs updated now that RTR is providing the update_type
field.
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.
suggestion: given the rationale for the ticket, I don't think this can live in the parser.
[...] this would allow [...] for Concentrate to source data from multiple sources to assign and adjust uncertainty values.
and
- Will be able to ingest multiple types of inputs to make adjustments to uncertainty in the future - this will only be used to make uncertainty changes based on OIO-indicated sign headway mode initially, but we'll be looking to make more substantial use of this in the future.
If it lives in the parser, there's no way for it to consume multiple sources of data.
Coverage of commit
|
do you mean the |
Coverage of commit
|
@paulswartz updated. This now also includes surfacing the value in the feed: https://app.asana.com/0/505721188639414/1206695607194179/f |
@bfauble I don't see the |
Enum.map(stus, fn stu -> | ||
StopTimeUpdate.update_uncertainty(stu, calculate_uncertainty(update_type)) | ||
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.
suggestion: since calculate_uncertainty
only depends on the update_type
you shouldn't calculate it within the map
.
|
||
defp set_uncertainty(update_type, stus) do | ||
Enum.map(stus, fn stu -> | ||
StopTimeUpdate.update_uncertainty(stu, calculate_uncertainty(update_type)) |
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.
question: this looks like it always sets the uncertainty
even if update_type
isn't set. won't this override the uncertainty we get from non-RTR sources?
end) | ||
end | ||
|
||
test "populates uncertainty in TripDescriptor based on update_type value of other" do |
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.
suggestion: can you add a test than an uncertainty
value without an update_type
is kept?
config/config.exs
Outdated
@@ -73,7 +73,8 @@ config :concentrate, | |||
Concentrate.GroupFilter.VehicleAtSkippedStop, | |||
Concentrate.GroupFilter.VehicleStopMatch, | |||
Concentrate.GroupFilter.SkippedStopOnAddedTrip, | |||
Concentrate.GroupFilter.TripDescriptorTimestamp | |||
Concentrate.GroupFilter.TripDescriptorTimestamp, | |||
Concentrate.GropuFilter.UncertaintyValue |
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.
suggestion: typo, should be Concentrate.GroupFilter.UncertaintyValue
Coverage of commit
|
…certainty value if update_type is not present
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.
Coverage of commit
|
Coverage of commit
|
This reverts commit 151d844.
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.
Performance looks better now!
Summary of changes
Asana Ticket: 🧠 Implement "uncertainty adapter" within Concentrate
Update to handle
update_type
field being present at theTripUpdate
level fromTripUpdates_enhanced.json
feed from RTR."mid_trip" == 60
"at_terminal" == 120
"reverse_trip" == 360