#3643 closed bug (fixed)
wrong direction of label direction symbol
Reported by: | strk | Owned by: | mhugent |
---|---|---|---|
Priority: | major: does not work as expected | Milestone: | Version 1.7.0 |
Component: | Symbology | Version: | Trunk |
Keywords: | label | Cc: | |
Must Fix for Release: | No | Platform: | Debian |
Platform Version: | Awaiting user input: | no |
Description
As you can see in the attached image, the "direction symbol" added by the label disagrees with the "direction symbol" of the line decoration.
I know the line decoration (the endpoint arrow) is correct. Note that line decoration was fixed by r15076 (see #3434) so a similar approach could be just copied over
The bug occurs with r11539 on a x84-64
Attachments (4)
Change History (15)
by , 13 years ago
Attachment: | wrong_orientation_label.png added |
---|
comment:1 by , 13 years ago
Owner: | changed from | to
---|
comment:2 by , 13 years ago
Seems to be vertical lines only. I attach a shapefile. Turn on arrows decoration on symbology-ng and orientation symbol on labels. Arrow decorations are correct.
by , 13 years ago
comment:4 by , 13 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Indeed r15591 fixed the attached edge.zip case, but it's still wrong for another dataset :/ I'm attaching it..
by , 13 years ago
Attachment: | qgisbug3643_1.zip added |
---|
comment:5 by , 13 years ago
In particular, edges with id 5 and 7 of qgisbug3543_1.zip are disagreed upon between label and line decoration. They are both going down, so line decoration is correct and label orientation symbol is wrong.
comment:6 by , 13 years ago
I'd add that the original testcase only contained lines oriented from bottom up, which may explain why this case wasn't cought.
by , 13 years ago
Attachment: | bug3643.diff added |
---|
comment:7 by , 13 years ago
The attached patch (bug3643.diff) fixes it for me, for both datasets. Might not be extremely elegant, but should be also more robust..
comment:8 by , 13 years ago
A slightly more elegant version:
diff --git a/src/core/pal/feature.cpp b/src/core/pal/feature.cpp index 6f657b1..5501434 100644 --- a/src/core/pal/feature.cpp +++ b/src/core/pal/feature.cpp @@ -596,7 +596,7 @@ namespace pal { //std::cout << alpha*180/M_PI << std::endl; if ( flags & FLAG_MAP_ORIENTATION ) - reversed = ( alpha > M_PI / 2 || alpha < -M_PI / 2 ); + reversed = ( (ex == bx && ey < by ) || ( alpha > M_PI / 2 || alpha < -M_PI / 2 ) ); if (( !reversed && ( flags & FLAG_ABOVE_LINE ) ) || ( reversed && ( flags & FLAG_BELOW_LINE ) ) ) positions->push_back( new LabelPosition( i, bx + cos( beta ) *distlabel , by + sin( beta ) *distlabel, xrm, yrm, alpha, cost, this, reversed ) ); // Line
comment:9 by , 13 years ago
Even smaller is just moving re-adding the equal sign but to the right part:
- reversed = ( alpha > M_PI / 2 || alpha < -M_PI / 2 ); + reversed = ( alpha > M_PI / 2 || alpha <= -M_PI / 2 );
Works fine in my case, altought the equality comparison between the return from atan2 and M_PI/2 looks scary (miracles!)
. |
comment:10 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Applied the second version in r15637. Thanks!
Is this only for vertical lines or for others too? Could you attach a small testdataset to reproduce the problem?