Fix workzone assignment #68
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
sgreenbury
changed the base branch from
main
to
16-filter-nts-data-to-study-area-to-avoid-unrepresentative-travel-distances-or-mode-share
sgreenbury
reviewed
Nov 18, 2024
Hussein-Mahfouz
merged commit aa9fdb9
into
16-filter-nts-data-to-study-area-to-avoid-unrepresentative-travel-distances-or-mode-share
4 checks passed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 PR fixes a bug in workzone assignment, specifically in the first point below
zones_to_time_matrixwas returning time estimates in seconds instead of minutes (see here). This was causing problems downstream as get_possible_zones compres reported NTS travel time (which is in minutes), to our time estimates, so our feasible_zones for each activity was only returning the origin zone. I have edited zones_to_time_matrix to return time in minutes: 596d2f8select_workzone_optimisationwas summing flows incorrectly. Actual flows were summed at the origin, while assigned_flows were summed at the destination, so the deviation calculation was not making sense. I have fixed that here: 37787ad