-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
make end of road non obvious #4411
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -327,6 +327,42 @@ std::size_t IntersectionHandler::findObviousTurn(const EdgeID via_edge, | |
return false; | ||
}(); | ||
|
||
// check whether we turn onto a oneway through street. These typically happen at the end of | ||
// roads and might not seem obvious, since it isn't always as visible that you cannot turn | ||
// left/right. To be on the safe side, we announce these as non-obvious | ||
const auto turns_onto_through_street = [&](const auto &road) { | ||
// find edge opposite to the one we are checking (in-road) | ||
const auto in_through_candidate = | ||
intersection.FindClosestBearing(util::bearing::reverse(road.bearing)); | ||
|
||
const auto &in_data = node_based_graph.GetEdgeData(in_through_candidate->eid); | ||
const auto &out_data = node_based_graph.GetEdgeData(road.eid); | ||
|
||
// by asking for the same class, we ensure that we do not overrule obvious by road-class | ||
// decisions | ||
const auto same_class = in_data.road_classification == out_data.road_classification; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The implication here is a change in road class is always obvious already? Is this always the case? Where is it determined? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. not necessarily, but we check for a |
||
|
||
// only if the entry is allowed for one of the two, but not the other, we need to check. | ||
// Otherwise other handlers do it better | ||
const bool is_oneway = !in_through_candidate->entry_allowed && road.entry_allowed; | ||
|
||
const bool not_roundabout = | ||
!(in_data.roundabout || in_data.circular || out_data.roundabout || out_data.circular); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Care to remind me about the difference between checking for the roundabout instruction and the roundabout data here? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. roundabout instructions can only be checked after they have been assigned. We are in the process of assigning turn-types, so they cannot be checked. |
||
|
||
// for the purpose of this check, we do not care about low-priority roads (parking lots, | ||
// mostly). Since we postulate both classes to be the same, checking one of the two is | ||
// enough | ||
const bool not_low_priority = !in_data.road_classification.IsLowPriorityRoadClass(); | ||
|
||
const auto in_deviation = angularDeviation(in_through_candidate->angle, STRAIGHT_ANGLE); | ||
const auto out_deviaiton = angularDeviation(road.angle, STRAIGHT_ANGLE); | ||
// in case the deviation isn't considerably lower for the road we are turning onto, | ||
// consider it non-obvious. The threshold here requires a slight (60) vs sharp (120) | ||
// degree variation, at lest (120/60 == 2) | ||
return is_oneway && same_class && not_roundabout && not_low_priority && | ||
(in_deviation / (std::max(out_deviaiton, 0.5)) <= 2); | ||
}; | ||
|
||
if (best_over_best_continue) | ||
{ | ||
// Find left/right deviation | ||
|
@@ -366,8 +402,7 @@ std::size_t IntersectionHandler::findObviousTurn(const EdgeID via_edge, | |
angularDeviation(intersection[right_index].angle, STRAIGHT_ANGLE); | ||
|
||
// return best_option candidate if it is nearly straight and distinct from the nearest other | ||
// out | ||
// way | ||
// out way | ||
if (best_option_deviation < MAXIMAL_ALLOWED_NO_TURN_DEVIATION && | ||
std::min(left_deviation, right_deviation) > FUZZY_ANGLE_DIFFERENCE) | ||
return best_option; | ||
|
@@ -385,8 +420,7 @@ std::size_t IntersectionHandler::findObviousTurn(const EdgeID via_edge, | |
right_data.road_classification); | ||
|
||
// if the best_option turn isn't narrow, but there is a nearly straight turn, we don't | ||
// consider the | ||
// turn obvious | ||
// consider the turn obvious | ||
const auto check_narrow = [&intersection, best_option_deviation](const std::size_t index) { | ||
return angularDeviation(intersection[index].angle, STRAIGHT_ANGLE) <= | ||
FUZZY_ANGLE_DIFFERENCE && | ||
|
@@ -400,6 +434,11 @@ std::size_t IntersectionHandler::findObviousTurn(const EdgeID via_edge, | |
if (check_narrow(left_index) && !obvious_to_left) | ||
return 0; | ||
|
||
// we are turning onto a through street (possibly at the end of the road). Ensure that we | ||
// announce a turn, if it isn't a slight merge | ||
if (turns_onto_through_street(intersection[best_option])) | ||
return 0; | ||
|
||
// checks if a given way in the intersection is distinct enough from the best_option | ||
// candidate | ||
const auto isDistinct = [&](const std::size_t index, const double deviation) { | ||
|
@@ -437,6 +476,11 @@ std::size_t IntersectionHandler::findObviousTurn(const EdgeID via_edge, | |
if (std::abs(best_continue_deviation) < 1) | ||
return best_continue; | ||
|
||
// we are turning onto a through street (possibly at the end of the road). Ensure that we | ||
// announce a turn, if it isn't a slight merge | ||
if (turns_onto_through_street(intersection[best_continue])) | ||
return 0; | ||
|
||
// check if any other similar best continues exist | ||
std::size_t i, last = intersection.size(); | ||
for (i = 1; i < last; ++i) | ||
|
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 is getting a bit out of hand with all the inline lambdas etc.
Do you think we could refactor the intersection handler a bit to make it easier to follow the logic here?
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.
we could, but that is not the scope of this PR