Bug report #6835
Label with "using perimeter" option looses label and do not work as expected
| 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: | fixed/implemented |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 15973 |
Description
Hi,
Using perimeter labeling option is not working well when labeling a polygon not entirely contained in mapCanvas extent. Polygon is clipped with extent and label is applied to that part.
Two major drawbacks:
- when using options above-on-below line, some labels are drawn outside screen extent. See joined screen capture. when using below line option, label disappear at the bottom and right side of the canvas. Reversed behaviour for "above" option. Half cut label for "On" OPtion
- Apart from drawing labels outside the screen, thhos labels shouldn't be drawn on Side of mapCanvas, but following the uncropped lines inside mapCanvas? See third image that simulate the theorical behaviour expected.
As a solution, I suggest that polygons intersecting current extent be converted to lines and clipped with extent, and labeled with same algorithm as "Line" uses. That way, only real boundary can be used to label polygon. That would solve both issues.
regards.
I'm affecting it to Larry because I know he has a good global vision of labeling tools. Feel free to reaffect
Régis
History
#1
Updated by Larry Shaffer over 11 years ago
- Status changed from Open to Feedback
Hi Régis,
This issue may be solved by implementing a separate feature request. See "Add option to have boundaries of map canvas's current extent act as obstacles to labels" under Placement options in New Labeling changes and roadmap.
Essentially, this would not affect the geometries (clipped or not) used for the perimeter labeling. What it would do however is to make the extent's geometry a feature(s) that is considered an obstacle to labels. I'm looking at making that obstacle variable in size, e.g. (extent - [px- or map unit-sized buffer]). This would keep the extent-clipped-edge labels from being considered as candidates for perimeter labeling as well. This also helps greatly for QGIS Server, where problem labels (as you have indicated) cause issues when generating/caching tiles.
I am looking to implement that sometime this month (Dec. 2012).
Note: could you add the screen snaps you reference?
#2
Updated by Regis Haubourg over 11 years ago
- File label_using_perimeter_wished.png added
- File label_using_perimeter_above_line.png added
- File label_using_perimeter_below_line.png added
Here are the screenshots! sorry for that
#3
Updated by Regis Haubourg over 11 years ago
Considering the map canvas's extent as obstacles to labels seems a good idea, and maybe more simple to implement.
Just a few questions, won't it make an area free of any label in that variable buffer zone?
What about small parts of polygons that user would like to label anyway? Users may want to force labeling of those. Is option "Show all labels for this layer (including colliding labels)" a solution for that?
Thanks a lots
Régis
#4
Updated by Larry Shaffer over 11 years ago
regis Haubourg wrote:
Just a few questions, won't it make an area free of any label in that variable buffer zone?
Yes. But, isn't that the point? The buffer zone doesn't need to be much bigger than the individual perimeter lines of the extent. A user may want to increase the buffer when generating tiles (as an example).
What about small parts of polygons that user would like to label anyway? Users may want to force labeling of those. Is option "Show all labels for this layer (including colliding labels)" a solution for that?
I think an extent buffer zone would override any setting like "Show all labels for this layer (including colliding labels)" since such a setting would negate it. Assuming the small parts of the clipped polygon in question were still capable of being labeled, then setting a very thin extent buffer zone (as described above) might do the trick.
Concerning very small visible bits of features that generally wouldn't be labeled, that's another issue. Currently, if the label doesn't 'fit' within the length of the feature, it is not drawn. "Show all labels for this layer (including colliding labels)" will only show all labels that would generally be drawn, but skip hiding labels that would be hidden due to collisions, i.e. all overlaps of labels are allowed and shown.
#5
Updated by Sandro Santilli over 10 years ago
I'm also missing the "Line direction symbol" for perimeter labels, so I'd welcome threating polygon perimeters fully as lines too. Do you see any problem with that, Larry ?
#6
Updated by Giovanni Manghi almost 10 years ago
- Status changed from Feedback to Open
#7
Updated by Nyall Dawson over 7 years ago
- Resolution set to fixed/implemented
- Status changed from Open to Closed
Fixed in recent versions