Fix/adjust angles #4630
Fix/adjust angles #4630
Conversation
There was a problem hiding this comment.
LGTM! But i found one weired thing that happens with the new test that is not related to the PR: bearing computation is not translational invariant. Just adding one node like
a
k b
/ |
c d - e
| |
| |
| |
| |
| |
| |
| |
| |
g f
makes expectations completely different
| @@ -105,6 +106,8 @@ class GeojsonLogger | |||
| std::lock_guard<std::mutex> guard(lock); | |||
| ofs.open(logfile, std::ios::binary); | |||
|
|
|||
| ofs << std::setprecision(12); | |||
There was a problem hiding this comment.
👍 why not auto old_precision = ofs.precision(12); where custom precision is needed (i guess for geometry) and after the output ofs.precision(old_precision);?
There was a problem hiding this comment.
Well, since the only purpose of this logger is to output map geometry, and the guard manages the stream and does the writing, I felt like a general increase in accuracy would not hurt
There was a problem hiding this comment.
There's a state restorer for this in Boost
http://www.boost.org/doc/libs/1_64_0/libs/io/doc/ios_state.html
MoKob
force-pushed
the
fix/adjust_angles
branch
from
854a963
to
0bb085a
Compare
Issue
The result is best visualised by comparing the testcases in perception.feature.
This PR changes the behaviour of how we adjust angles at an intersection right before a merge.
It turns out that we can introduce worse turn-angles, if the straightest turn out of the intersection isn't improved.
This is a changed branched out from #4426
Tasklist
Requirements / Relations
A map for all affected locations can be found here. In all of these cases, the angle isn't messed with. It is hard to clearly visualise what happens, but the angles would reflect most turn angles better.