Bug report #2113

curved labels: only a few are drawn

Added by Paolo Cavallini about 10 years ago. Updated about 1 year ago.

Status:Open
Priority:Normal
Assignee:-
Category:Labelling
Affected QGIS version:3.2 Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:
Crashes QGIS or corrupts data:No Copied to github as #:12173

Description

With the new labelling engine, I always get far too few labels when selection the "curved" option. See attached screenshot an sample file.

labels.png - example of missing labels (134 KB) Paolo Cavallini, 2009-11-19 12:50 AM

fiumi-princ.zip - sample file to show problems in labelling (184 KB) Paolo Cavallini, 2009-11-19 12:52 AM

labels2-composer.png - Example 2: labels in the composer window (still ok) (89.6 KB) Borys Jurgiel, 2010-07-06 11:22 PM

labels2-printout.pdf - Example 2: labels on printout (82.6 KB) Borys Jurgiel, 2010-07-06 11:22 PM

P1080123_cropped_1.jpg - Check out the labelling on the roads. Sorry about the poor lighting :( (254 KB) Alister Hood, 2011-02-10 07:28 PM

qgis_2113_parallel.png (425 KB) Tom Grundy, 2018-10-14 07:51 PM

qgis_2113_curved.png (271 KB) Tom Grundy, 2018-10-14 07:51 PM


Related issues

Related to QGIS Application - Bug report #6763: Labels don't wrap around 90 degree bend Closed 2012-11-26
Duplicated by QGIS Application - Feature request #10740: Curved labelling should fall back to parallel labels for ... Open 2014-06-26

History

#1 Updated by Martin Dobias about 10 years ago

The problem is that either the shapes are too short (the label wouldn't fit on the line) or the shapes are too complex and creation of labels candidates fails because the succesive characters would be otherwise rotated "too much", resulting in unreadable labels.

I don't know what should be a correct solution for this. The engine could try to detect such complex shapes and try to simplify on-the-fly them before creating candidates...

#2 Updated by Borys Jurgiel over 9 years ago

Even on simpler lines, as streets, the curvature threshold seems too low. I can imagine much more curved labels would be still good-looking. Anyway, even if it's acceptable on display, on printouts (or exported files; no matter rasterized or not) it is definitely not. See screenshots label2-* (also wrong scaling and #2796 are visible).

#3 Updated by Alister Hood almost 9 years ago

(sorry, I was meant to post this before attaching)

I agree with this:

Even on simpler lines, as streets, the curvature threshold seems too low.

But I also think that this is necessary:

The engine could try to detect such complex shapes and try to simplify on-the-fly them before creating candidates...

See the labelling on the roads in P1080123_cropped_1.jpg for an example.

#4 Updated by Paolo Cavallini over 8 years ago

  • Pull Request or Patch supplied set to No
  • Tracker changed from Bug report to 4
  • Start date set to 2011-07-25

#5 Updated by Giovanni Manghi almost 8 years ago

  • Target version changed from Version 1.7.0 to Version 1.7.4

#6 Updated by Giovanni Manghi over 7 years ago

  • Affected QGIS version set to master
  • Tracker changed from 4 to Bug report
  • Crashes QGIS or corrupts data set to No

#7 Updated by Giovanni Manghi over 7 years ago

  • Operating System deleted (Debian)
  • Priority changed from Low to Normal
  • Status info deleted (0)

see also #4855

#8 Updated by Paolo Cavallini over 7 years ago

  • Target version changed from Version 1.7.4 to Version 1.8.0

#9 Updated by Giovanni Manghi over 7 years ago

  • Category changed from Symbology to Labelling

#10 Updated by Paolo Cavallini about 7 years ago

  • Target version changed from Version 1.8.0 to Version 2.0.0

#11 Updated by Giovanni Manghi about 7 years ago

  • Assignee changed from Martin Dobias to Larry Shaffer

#12 Updated by Anita Graser about 7 years ago

  • Priority changed from Normal to High

#13 Updated by Larry Shaffer almost 7 years ago

  • Status changed from Open to In Progress

See #6763-6 for update on related issue.

Please test with ee12df2 and inside and outside angles greater than 20 to see higher label count (especially if you still have the original data). Some comparison screen snaps again would be nice.

Any settings higher than inside of 30 or outside of 50 (and possibly lower in some cases) will start producing some funky-looking labels. QGIS <= 1.8 had a setting of 20 for both angles.

#14 Updated by Giovanni Manghi almost 7 years ago

  • Priority changed from High to Normal

#15 Updated by Paolo Cavallini almost 6 years ago

  • Target version changed from Version 2.0.0 to Future Release - High Priority

#16 Updated by Paolo Cavallini over 5 years ago

Still far from optimal

#17 Updated by Paolo Cavallini over 5 years ago

Partly duplicated in #10740

#18 Updated by aperi2007 - over 5 years ago

Hi,
in #10740.
I give a potential solution.
My solution is to enhance the code to support an optionally second change to not lost any label that don't allow to be curved. Putting it parallel.

It is quite flexible because it give the grant to not lost any label.

Actually no one of out power users use the curve string solution. Because they are always the question to know if lost any label.
Out map infct could not lost any label.And so they use always the parallel strings to be sure to have all the labels.

I guess the parallel string as an otherwise solution could be supported using a checkbox to active it optionally.
This probably could help to use the curve solution.

I like to know if this feature could be accepted.

Please note that don't mean that we are capble to fund this solution.
This is only a proof of concept to understand if there is a potential solution for this.

One time to decide what is the solution.
The second point is understand how much cost to develope it.
:)

Regards,

Andrea.

#19 Updated by Paolo Cavallini over 5 years ago

As discussed on the mailing list long ago, probably the best approach would be to simplify (generalize) complex (multi)lines on the fly, so that the labels will follow the best approximation to the original curve, without becoming too garbled or disappearing altogether.
I suggest to use a similar approach to geometry simplification done by Alvaro, maybe even some of the same functions.

#20 Updated by aperi2007 - over 5 years ago

The simplify approach is could be affordable for a print goal .
But could be too slowly for a web browsing map.

Almost if the question is a run-time simplify approach.

Are you speaking of an extra layer maually added to the project and simplified previously offline.
Rendered also with 100% transparency and used to obtain the curved label ?

I guess the primary question is not resolved however.
Infact after the simplify, no-one could know if the simplify was sufficient to avoid the lost of the label.

Or you are speaking of an iterative simplification increasing the simplify untile the label could appear ?

This could work but I guess it could be mortally slow.
Not more on qgis-desktop where the asynchornocity of the multithread could assure to do this meanwhile qgis do other thinks,
but instead on qgis-server where the mp is before produce and after send.

It could slow the map production of an impredictable time due to the situation of label on that portion f map.

A.

#21 Updated by Paolo Cavallini over 5 years ago

I suggest the same approach as Alvaro OTF simplification, which is actually quite fast.
The default could be crafted so as to show all the labels, or this could be forced with an option.

#22 Updated by aperi2007 - over 5 years ago

Hi,

we like to understand if this problem is resolvable or not.

The solution proposed:

As discussed on the mailing list long ago, probably the best approach would be to simplify (generalize) complex
(multi)lines on the fly, so that the labels will follow the best approximation to the original curve, without
becoming too garbled or disappearing altogether.

I guess in not a sure solution.
I understand it augment the statistically of label curved used, and reduce the statistical of label lost, but we need to have Label Lost = 0 (zero) .

The try to introduce this need n a simplifiy algorithm will introduce an iterative procedure that could put the time to elaborate to infinite.

I guess to grant this is necessary to introduce a rule specific like this:
is the single label is not fittable in a curved line it will put parallel.

#23 Updated by Giovanni Manghi over 2 years ago

  • Regression? set to No
  • Easy fix? set to No

#24 Updated by Paolo Cavallini almost 2 years ago

Still true in master.

#25 Updated by Paolo Cavallini over 1 year ago

  • Assignee deleted (Larry Shaffer)
  • Affected QGIS version changed from master to 3.0.0

#26 Updated by Tom Grundy about 1 year ago

This problem still exists in 3.2.1. I tried increasing letter spacing and changing to all-caps for the letter sizes to be more predictable, but did not see any improvement. Images attached with labeling set to parallel and another with labeling set to curved with no other changes.

#27 Updated by Giovanni Manghi about 1 year ago

  • Status changed from In Progress to Open
  • Affected QGIS version changed from 3.0.0 to 3.2

Also available in: Atom PDF