-
Notifications
You must be signed in to change notification settings - Fork 661
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
Check for complex restriction where bidirectional expansion meets #2242
Conversation
Adds jönköping tiles for complex restrictions test on short paths Prevents parallel runs of valhalla_build_timezones Adds lock around valhalla_build_timezones Adds test with complex restriction where bidirectional meet The edge that connects the two directions of expansion in Bidirectional is dropped if it is part of a complex restriction. The correct behaviour is instead to walk the edges back and forth to see if any complex restriction really is active. References #2228 Resolves added transition_cost from previous merge from master WIP `IsBridgingEdgeRestricted` Implements IsBridgingEdgeRestricted in forward direction Adds tests for complex restrictions for `IsBridgingEdgeRestricted` Adds failing test with BidirectionalAStarSingleDirection Back to BidirectionalAstar, test fails without forwardexpansion Implements IsBridgingEdgeRestricted in reverse direction WIP: Realises it is harder than expected to check opposing tree of expansion Adds complexrestriction::CheckPatchPathForRestrictions which checks a patch-path against a list of restrictions Added unittest test_IsBridgingEdgeRestricted which passes all astar tests pass Remove couts Restored DynamicCost::Restricted api More comment Removes dead code More cleanup of unneeded changes Try different protobuf api CircleCI has old protobuf Cleaning up Tiles with greg astar tests passing clean up. added reverse logic for the restriction.
…-short-paths-clean-3
[ FAILED ] Astar.test_complex_restriction_short_path_melborne [ FAILED ] Astar.test_IsBridgingEdgeRestricted
src/thor/bidirectional_astar.cc
Outdated
patch_path.push_back(edgeid); | ||
|
||
// Also grab restrictions while walking for later comparison against patch_path | ||
// |
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.
extra comment
// | ||
tile = graphreader.GetGraphTile(edgeid, tile); | ||
if (tile == nullptr) { | ||
throw std::logic_error("Tile pointer was null in IsBridgingEdgeRestricted"); |
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 just cant happen, because the edge is coming from the path that the algorithm was expanding
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.
I think it is fine to have some kind of check around "impossible" states. Would you prefer to log an error message or some other effect?
} | ||
const auto& edge = tile->directededge(edgeid); | ||
if (edge == nullptr) { | ||
throw std::logic_error("Edge pointer was null in IsBridgingEdgeRestricted"); |
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.
same
break; | ||
} | ||
next_rev_pred = edge_labels_rev[next_rev_pred_idx]; | ||
if (!next_rev_pred.on_complex_rest()) { |
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.
i remember mentioning about breaking early when we reviewed this a bit ago. was this the change to do that. for some reason i thought that we needed the tile to do the check but honeslty my memory is fading
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.
The edge carries the bit describing the existence of any complex restriction. We probably conflated this with checking for the full set of matching restrictions from tile->GetRestrictions
.
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.
looks good just some small comments and questions following up from the last review we did
9ea5709
to
b0cb1e6
Compare
test/astar.cc
Outdated
} | ||
auto correct_len = 5; | ||
ASSERT_EQ(paths.size(), correct_len) << "Wrong number of paths in response"; | ||
//{ |
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.
Hmm this isn't supposed to be commented.
… label, fix up a* fake tile setup
This PR is just waiting on RAD testing at the moment. I'll do some rounds of that tomorrow to verify the differences. Otherwise this is ready to ship. |
I ran RAD tests on a common set of routes with no diff to master. Running a second set of RAD on a complex restriction dense area shows good improvements in time and length of routes. |
…populate the segments * master: Transition matching (#2258) Post merge feedback on #2253. (#2257) Check for complex restriction where bidirectional expansion meets (#2242) Update README.md Configurable load testing of /route and /trace_route endpoints (via wrk) (#2253) Polyline Resampling Addition and Bug Fix (#2239) Update exit logic for non-motorways (#2252) Add app. to get a list of elevation tiles that are covered within the (#2248) Fix RapidJSON warnings and naming conflicts (#2249) Add basic truck costing documentation (#2241) # Conflicts: # test/mapmatch.cc
Issue
This PR adds an improved check of complex restrictions on the bridging edge that connects the two search directions in Bidirectional astar.
See linked issue for more detailed information.
Fixes #2228
Tasklist
Requirements / Relations
Link any requirements here. Other pull requests this PR is based on?