-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Improve Turn Angles #2779
Improve Turn Angles #2779
Conversation
I've implemented a first crack at resolving #2778 . The change results in updated turn angles on Berlin in many cases. If only printing changes of at least 20 degrees, we see changes reflected in the following list: Changed Angle from 75.6269169146 to 97.6369878691 at: 52.537318 13.360354 I am verifying this list to see whether these changes can be considered reasonable or not. Edit: I've reduced the list to a set of problematic cases I've seen. Further verification is ongoing. |
From what I've seen in the changes: the most angles affected very strongly are turn-lanes in between two ways representing the same road, roads splitting into two ways and turning roads/traffic circles. The affected angles for splitting roads are most times alright, but can offer too strong variations in my view. I have to check more items to see the effect in a global scenario. Any curve in a road is usually difficult to begin with. The angles seem a bit off to me. Will need to investigate this further. |
should be turn-left (requires angle adjustment in collapsing) |
3b89d51
to
7c15d0b
Compare
54819fb
to
2eab4c6
Compare
#2937 is somewhat standing in our way. |
1139615
to
2497409
Compare
Apparently one of the tests only succeeded due to a sliproad detection. This detection has changed. The test needs investigation to make it pass again. |
2497409
to
87482f8
Compare
Circle Offsets are currently offering strange results. Needs further investigation. |
@MoKob care to elaborate on these images? Color reflects angle? |
Greenish colours are coordinates of the connected roads. Blue are the three coordinates chosen to calculate the turn angle. On the satellite image you can see that the angles better describe the actual turn here. |
return this.extractInstructionList(instructions, s => s.maneuver.bearing_before + '->' + s.maneuver.bearing_after); | ||
return this.extractInstructionList(instructions, s => ('in' in s.intersections[0] ? this.reverseBearing(s.intersections[0].bearings[s.intersections[0].in]) : 0) | ||
+ '->' + | ||
('out' in s.intersections[0] ? s.intersections[0].bearings[s.intersections[0].out] : 0)); |
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 change uses the bearing array instead of the parameters we want to deprecate anyhow.
INVALID_ENTRY_CLASSID, | ||
datasource_vector[segment_idx], | ||
util::guidance::TurnBearing(0), | ||
util::guidance::TurnBearing(0)}); |
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 rest of this part was not aligned properly. The addition of the turn-bearings is the only change here.
unpacked_path.back().turn_instruction = turn_instruction; | ||
unpacked_path.back().duration_until_turn += (edge_data.distance - total_weight); | ||
unpacked_path.back().pre_turn_bearing = facade.PreTurnBearing(edge_data.id); | ||
unpacked_path.back().post_turn_bearing = facade.PostTurnBearing(edge_data.id); |
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.
... and here
@@ -34,7 +34,7 @@ const int constexpr MAX_SLIPROAD_THRESHOLD = 250; | |||
// Road priorities give an idea of how obvious a turn is. If two priorities differ greatly (e.g. | |||
// service road over a primary road, the better priority can be seen as obvious due to its road | |||
// category). | |||
const double constexpr PRIORITY_DISTINCTION_FACTOR = 2.0; | |||
const double constexpr PRIORITY_DISTINCTION_FACTOR = 1.75; |
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.
turned out the obvious detection was a bit to restrictive 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.
Trophy for best ASCII Cucumber scenarios! More seriously, wow those are detailed and describe their OSM link - thanks for that!
Most of the (i, i+-1) code could benefit from some stdlib algorithms (check algorithms and numeric header).
I think the two major issues are possible iterator invalidation and the accumulate with int.
| de | | bot | primary | yes | | ||
| dr | | off | primary | yes | | ||
| gj | | bot | primary | yes | | ||
| jk | | bot | primary | yes | |
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.
Thanks for fixing!
| waypoints | route | turns | | ||
| k,j | on,ferry,,ferry,off,off | depart,notification straight,continue uturn,turn straight,notification straight,arrive | | ||
| waypoints | route | turns | | ||
| k,j | on,ferry,road,road,ferry,off,off | depart,notification straight,notification straight,continue uturn,turn straight,notification straight,arrive | |
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 changes in route and turns here is not only related to only ga
being a ferry now?
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 change is including ab
as non-ferry. The problem we were trying to check here was having mode-changes (notifications) visible. This was not the case without the change anymore.
| | ||
| | ||
| | ||
d |
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 ~7 meter here is compensated by abc having 4 lanes, right?
| | ||
| | ||
| | ||
d |
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.
.. and no longer here since it's still 4 lanes but more like 20 meters?
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.
Exactly. Lanes influence how a road is seen. If the modelled road takes a turn right after it reaches the border of the road, the turn itself is most likely describing a typical phenomenon in osm which i modelled in #2778 (comment).
When I route I should get | ||
| waypoints | route | turns | | ||
| a,b | road,road | depart,arrive | | ||
| a,i | road,road,road | depart,continue uturn,arrive | |
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.
Hm is there a limit on the uturn's road length? I can see how this is a uturn with this small of a grid size, what about larger ones?
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.
Yes. There is a limit on how long this road can become.
const auto slope = dividend / divisor; | ||
const auto intercept = (sum_lat - slope * sum_lon) / coordinates.size(); | ||
|
||
const auto GetLatatLon = |
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.
At
} | ||
} | ||
else | ||
{ | ||
if (angularDeviation(left.turn.angle, 270) > angularDeviation(right.turn.angle, 270)) | ||
if (angularDeviation(left.turn.angle, 265) >= angularDeviation(right.turn.angle, 265)) |
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.
Oh? Can you explain the changes for the lines above?
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.
essentially gives a little bit of wiggle room. 270 is perfectly left.
&guidance::RoadClassification::SetClass) | ||
.property("num_lanes", | ||
&guidance::RoadClassification::GetNumberOfLanes, | ||
&guidance::RoadClassification::SetNumberOfLanes), |
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.
There are road width tags (e.g. http://taginfo.openstreetmap.org/keys/width#combinations) - do you think it could make sense to use those for shortcutting the width calculation via lanes?
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.
Added to #3055
static_cast<double>(toFloating(first_coordinate.lon)) * | ||
static_cast<double>(toFloating(third_coordinate.lat)) + | ||
static_cast<double>(toFloating(second_coordinate.lon)) * | ||
static_cast<double>(toFloating(third_coordinate.lat))); |
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.
Hm. Maybe make some tmp. vars for the calculation, this is somewhat hard to read.
@@ -188,6 +188,8 @@ | |||
{"key": "highway", "value": "default"}, | |||
{"key": "width", "description": "Penalties for narrow streets"}, | |||
{"key": "lanes", "description": "Penalties for shared single lane streets"}, | |||
{"key": "lanes:forward", "description": "Lanes in forward direction"}, | |||
{"key": "lanes:back", "description": "Lanes in backward direction"}, |
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.
Hm I can't see those getting used, also it should be backward I suppose?
d3bfae5
to
bee0614
Compare
@daniel-j-h what about the changes? Would love to get this off my plate |
Thank you for the adjustments. |
This PR adds more advanced coordinate extraction, analysing the road to detect offsets due to OSM way modelling. In addition it improves the handling of bearings. Right now OSM reports bearings simply based on the very first coordinate along a way. With this PR, we store the bearings for a turn correctly, making the bearings for turns correct.
This PR addresses the improvement of turn angles raised in #2778.
resolves in #2778
resolves #2937
TODO
Right now I see multiple strategies that I will update the PR with to report on my findings:
- [ ] Average Turn Angle among multiple coordinatesn
meters for the turn (see here)In addition: