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

Reject alternatives with too long detours #3238

Merged
merged 4 commits into from
Jul 28, 2021
Merged

Conversation

genadz
Copy link
Contributor

@genadz genadz commented Jul 27, 2021

Issue

A motivation of this PR is to reject bad alternatives that have unreasonable long detours comparing to the optimal route.

Code is simple enough: find a different segment for two routes and compare their costs. In case cost of alternative segment is much bigger than cost of the optimal segment -> reject such alternative.

Tasklist

  • Add tests
  • Add #fixes with the issue number that this PR addresses
  • Update the docs with any new request parameters or changes to behavior described
  • Update the changelog
  • If you made changes to the lua files, update the taginfo too.

Requirements / Relations

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

| |
E-F
)";
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typical example of an alternative that should be rejected by these changes

@@ -15,7 +15,13 @@ using namespace valhalla::midgard;
*/
namespace {
// Defaults thresholds
// TODO: global stretch parameter should depend on the optimal route cost/duration.
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'm sure that we miss some good alternatives for short routes because of one global threshold. Added as "TODO", but it should be transformed into an issue/PR

Copy link
Contributor Author

@genadz genadz Jul 27, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and, imho, we should also refactor max_sharing (https://github.com/valhalla/valhalla/blob/master/src/thor/alternates.cc#L25-L47) coefficient in the following way:

  1. a little bit increase max_sharing coefficient for shorter routes. I think value 0.6 for routes < 20km is too strict, it should be ~0.7.
  2. replace piecewise constant function with a smoother one (cubic?) to ensure that for two close routes max_sharing constant values also will be close. It's a little bit strange that for 9.9-km route we will use max_sharing constant equals to 0.5 but for 10-km route this constant will be 0.6.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

both of these suggestions make way more sense to me as well 👍

@genadz
Copy link
Contributor Author

genadz commented Jul 27, 2021

  1. No changes in performance.
  2. This change affects ~1-2% of routes. Let me share several examples:

No good alternatives were found

before after
1_before 1_after
2_before 2_after
3_before 3_after

Other alternatives were proposed

before after
4_before 4_after
5_before 5_after
6_before 6_after

Comment on lines 109 to 110
const auto& idxs_opt = diff_segment.first;
const auto& idxs_alt = diff_segment.second;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this naming is difficult for my brain. idxs_opt is the segment of the optimal path which is different and idxs_alt is the segment of the candidate path that is different. what about like unique_optimal_segment and unique_candidate_segment? maybe also diff_segment would be like unique_segments? i dont know just a suggestion, though pretty long names...

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 like that, thank you !

const auto& idxs_opt = diff_segment.first;
const auto& idxs_alt = diff_segment.second;

if (idxs_opt.first == optimal_path.size()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we could use a comment here i think, its hard to understand that this is really the second clause of the comment in the next if block. basically its saying, there was no start to a unique part in the optimal path, as all its edges were found in the alternate path. then the second if is really saying there was a unique part in the alternate path past the end of the optimal, which is just wasteful so reject it

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

by the way is there any way to make that happen in gurka? im guessing its pretty difficult. you have to have two loki::search candidates on both locations so that the search paths can go the "wrong" way and then meet after the "right" way finds the optimal route

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've met such corner case when tested this PR; but it's difficult to reproduce

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no worries, just wondered if you tried

kevinkreiser
kevinkreiser previously approved these changes Jul 27, 2021
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.

this looks great to me. if you could comment a little more the logic in the main function and if you can figure out how to test those pathological cases that would be great but this is good either way

@genadz genadz merged commit 05ab193 into master Jul 28, 2021
@genadz genadz deleted the kgv_fix_bounded_stretch branch July 28, 2021 08:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants