Skip to content
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

Merged
merged 35 commits into from
Feb 29, 2020

Conversation

purew
Copy link
Contributor

@purew purew commented Feb 17, 2020

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

  • Add tests
  • Add #fixes with the issue number that this PR addresses
  • Generally use squash merge to rebase and clean comments before merging
  • Update the changelog

Requirements / Relations

Link any requirements here. Other pull requests this PR is based on?

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.
[  FAILED  ] Astar.test_complex_restriction_short_path_melborne
[  FAILED  ] Astar.test_IsBridgingEdgeRestricted
patch_path.push_back(edgeid);

// Also grab restrictions while walking for later comparison against patch_path
//
Copy link
Member

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");
Copy link
Member

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

Copy link
Contributor Author

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");
Copy link
Member

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()) {
Copy link
Member

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

Copy link
Contributor Author

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.

kevinkreiser
kevinkreiser previously approved these changes Feb 17, 2020
Copy link
Member

@kevinkreiser kevinkreiser left a 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

@purew purew force-pushed the complex-restriction-short-paths-clean-3 branch from 9ea5709 to b0cb1e6 Compare February 21, 2020 15:42
test/astar.cc Outdated
}
auto correct_len = 5;
ASSERT_EQ(paths.size(), correct_len) << "Wrong number of paths in response";
//{
Copy link
Contributor Author

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.

@kevinkreiser
Copy link
Member

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.

@purew
Copy link
Contributor Author

purew commented Feb 28, 2020

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.

@purew purew merged commit 4559af9 into master Feb 29, 2020
yuzheyan added a commit that referenced this pull request Mar 2, 2020
* master:
  Post merge feedback on #2253. (#2257)
  Check for complex restriction where bidirectional expansion meets (#2242)
  Update README.md
yuzheyan added a commit that referenced this pull request Mar 3, 2020
…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
@purew purew deleted the complex-restriction-short-paths-clean-3 branch March 10, 2020 21:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Check for complex restriction where bidirectional expansion meets
3 participants