Bug report #6763
Labels don't wrap around 90 degree bend
Status: | Closed | ||
---|---|---|---|
Priority: | Normal | ||
Assignee: | Larry Shaffer | ||
Category: | Labelling | ||
Affected QGIS version: | master | Regression?: | No |
Operating System: | Easy fix?: | No | |
Pull Request or Patch supplied: | No | Resolution: | end of life |
Crashes QGIS or corrupts data: | No | Copied to github as #: | 15916 |
Description
Curved labels don't seem to like wrapping around 90 degree corners. See images for examples and an example from MapServer that is the correct behavior.
23m label height @ 1:5103m scale
23m label height @ 1:10000m scale
MapServer with correct label wrapping at 1:10000
Related issues
History
#1 Updated by Nathan Woodrow almost 12 years ago
- File labeltest.zip added
Added sample data and fixed images.
#2 Updated by Nathan Woodrow almost 12 years ago
- Subject changed from Label don't wrap around 90 degree bend to Labels don't wrap around 90 degree bend
#3 Updated by Martin Dobias almost 12 years ago
There's a constant (max_char_angle_delta in src/core/pal/feature.h) that limits the maximum angle difference allowed between two characters. Currently it is not exposed to outside world (although it could be) and the allowed difference is set to 20 degrees - this is to avoid ugly labels for lines that quickly change direction.
#4 Updated by Larry Shaffer almost 12 years ago
- Status changed from Open to Feedback
Hi Martin,
Since there is now letter and word spacing for curved labels, I think exposing that option, at layer and maybe data defined levels, is be a good idea. Are you working on it? If not, I think I have time today to do it (home from work with a bad cold).
#5 Updated by Larry Shaffer almost 12 years ago
Hi Nathan and Martin,
I have implemented this in a feature branch at my forked repo:
https://github.com/dakcarto/Quantum-GIS/tree/labeling_max-char-angle-delta_1
Currently, it works with angles from 20-90 degrees, but that doesn't work quite right, yet. I think what it needs is the splitting of LabelInfo's max_char_angle_delta into inside and outside angles and angle_delta in feature.cpp adjusted to allow larger angles for outside than for inside.
Reason: in Nathan's example, having a 90 degree outside bend allows the label to wrap around feature, like desired, but the same 90 degree setting (at the layer level) will cause very poor-looking inside angle collisions between chars. In my quick visual testing, it looks like a max of 45-60 for inside and maybe just over 90 for outside angles would work well.
I will try adding splitting the inside/outside now. Any other ideas would be appreciated.
#6 Updated by Larry Shaffer almost 12 years ago
- File zoomed-out_in-40_x_out-70.png added
- Status changed from Feedback to In Progress
- File curved-chars_averaging.png added
- File zoomed-out_ins-20_x_out-20.png added
- File zoomed-in_in-40_x_out-70.png added
- File zoomed-in_in-20_x_out-20.png added
The wrapping issue should be addressed with commit ee12df2 'Add option to set inside and outside maximum for delta angle between curved label characters' (thanks for the pointer Martin)
When using these new curved label angle adjustments coupled with reasonable amounts of letter and word spacing, it dramatically increases the number of available candidates. See attachments for comparisons.
Settings used in comparisons
Text in map units, letter and word spacing of 10 map units, inside delta angle of 40 and outside of 70.
This doesn't mean all labels are readily legible and look nice. :^) This stems from PAL's curved label character placements currently being built without any feature simplification (as noted in #6200) or any post character-chain averaging. I think the latter is probably fairly straightforward to do, and would make the majority of high-delta angle labels look better. See curved-chars_averaging.png (only one candidate for clarity).
Averaging could possibly happen while the chain of characters is being built, or after. Basically, when any inside (and maybe some outside) high-delta angle overlaps occur, the related characters are rotated away from the overlap by 1/4 of the delta angle about the center of their bases (green dots in attachment). This would allow legibility to increase, but at the cost of slight misalignment of placement to feature. So, I think it should be optional, not automatic, with a user-defined percentage or min delta to trigger averaging. Since the individual characters are separate labels, it is possible to store the adjusted delta angle (and new x/y label origin point) without affecting the built character chain, allowing subsequent letters to stay 'on track' with original placement solution.
The averaging would be a bit more difficult to perform (or would be skipped) if there were character runs greater than 2 or 3 with overlaps. This means that averaging should probably occur after the full character chain is built.
Any opinions on that type of character averaging, or another approach (besides feature simplification), would be greatly appreciated.
#7 Updated by Larry Shaffer almost 12 years ago
- File Selection_011.png added
Note: the above commit addresses the wrapping issue, but not the alignment of the label (i.e., have the label centered on the middle point of the line, by default, like with MapServer). Even with one candidate the label tends toward the edge of the line (something similar has been reported in other issues). See Selection_011.png
#8 Updated by Alister Hood almost 12 years ago
Larry Shaffer wrote:
Note: the above commit addresses the wrapping issue, but not the alignment of the label (i.e., have the label centered on the middle point of the line, by default, like with MapServer). Even with one candidate the label tends toward the edge of the line (something similar has been reported in other issues). See Selection_011.png
Which isn't necessarily a bad thing. In some cases it may be preferable for the label to be in the middle of the line, but in other cases it is preferable for it to be on the straightest part of the line, or on the most horizontal of the parts of the line which are relatively straight for a length longer than the label, or something complicated like that ;)
#9 Updated by Jürgen Fischer over 10 years ago
- Target version changed from Version 2.0.0 to Future Release - Lower Priority
#10 Updated by Giovanni Manghi over 7 years ago
- Easy fix? set to No
- Regression? set to No
#11 Updated by Giovanni Manghi over 5 years ago
- Status changed from In Progress to Closed
- Resolution set to end of life
End of life notice: QGIS 2.18 LTR
Source:
http://blog.qgis.org/2019/03/09/end-of-life-notice-qgis-2-18-ltr/