Bug report #4317

New labeling: rotation for polygons is only applied after moving the label + the "issue" of needing the "X" and "Y" columns

Added by Giovanni Manghi about 8 years ago. Updated over 7 years ago.

Status:Closed
Priority:Normal
Assignee:Marco Hugentobler
Category:Labelling
Affected QGIS version:master Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:fixed
Crashes QGIS or corrupts data:No Copied to github as #:14254

Description

Pick a point layer with a field that holds angle value to give to labels. Set it in the data defined settings of the new labeling engine and you'll get rotated labels.

The same does not happen for polygons (didn't checked lines yet): labels do render horizontally and rotation is ONLY applied when EACH label is moved with the "move label" tool.

The explanation for this is not quite easy to understand (from the user point of view).

To activate the "rotation" field (as also the "horizontal alignment" and the "vertical alignment") the vector needs two columns "X" and "Y": for points - as user- I always assumed that this columns needed the actual coordinates of the points, so the user normally fill this fields (for example with the field calculator) and at the end it gets correctly rotated labels.

The need of those "X" and "Y" columns made me think that this feature was only available for points (what is the "X" and "Y" of a line or polygon?), but with my great surprise I discovered it works also for polygons: the "X" and "Y" columns do not need to be filled, nevertheless you can choose them in "data defined settings" and so then you can activate the "rotation" setting.

If the "X" and "Y" columns are empty, then the rotation value is ignored, but if you move a label the "X" and "Y" fields for that particular record are updated with values that seems be something like the centroid coordinate.

Resume:

  • the "rotation" field in only available if the vector has two columns "X" and "Y"
  • for points it seems natural to have them filled with point coordinated, then the rotation works ok
  • it works also for polygons, but is not really clear what values this field should carry
  • if the "X" and "Y" columns are available but are empty, then the rotation field is available but rotation values are ignored
  • then, if the label is moved the "X" and "Y" records for that particular feature are updated, and the rotation value is correctly applied

The above is quite counter-intuitive and for polygons (and also lines I guess) it can almost be considered a bug because is not clear at all what coordinates should be used to fill the "X" and "Y" columns. Moving by hand each label (to have those field automatically filled) it is not an option.

History

#1 Updated by Paolo Cavallini almost 8 years ago

  • Category changed from Symbology to Labelling

#2 Updated by Giovanni Manghi almost 8 years ago

  • Target version set to Version 1.7.4

#3 Updated by Paolo Cavallini over 7 years ago

  • Target version changed from Version 1.7.4 to Version 1.8.0
  • Affected QGIS version set to master
  • Crashes QGIS or corrupts data set to No

#4 Updated by Larry Shaffer over 7 years ago

Giovanni, the new Freeze/Thaw label tool will handle the need for populating the attribute tables with x, y and rotational label info. This allows for batch freezing of label properties to the table without using the Move Label tool on each label. The tool can also hide labels (set size to 0, if size is data-defined).

See: http://osgeo-org.1560.n6.nabble.com/New-adv-labeling-freeze-thaw-tools-td4988479.html

The Freeze/Thaw tool does not address the need for label rotation to be independent from x, y being defined.

#5 Updated by Gerhard Spieles over 7 years ago

In the old labeling engine, it is possible to set the rotation field without having x and y fields in the attribute table. Only a field with the rotation infomation is necessary.

For practicle work, it would be good to have this functionality also in the new labeling engine.

#6 Updated by Giovanni Manghi over 7 years ago

Larry Shaffer wrote:

Giovanni, the new Freeze/Thaw label tool will handle the need for populating the attribute tables with x, y and rotational label info. This allows for batch freezing of label properties to the table without using the Move Label tool on each label. The tool can also hide labels (set size to 0, if size is data-defined).

See: http://osgeo-org.1560.n6.nabble.com/New-adv-labeling-freeze-thaw-tools-td4988479.html

The Freeze/Thaw tool does not address the need for label rotation to be independent from x, y being defined.

Hi Larry,
thanks for your work.

Freezing the labels seems at least a good "workaround" to get those x/y columns populated and so the labels rotated.

I just gave it a try and I have a doubt: In a layer I set the x/y and rotation columns for labels. The latter one was already populated with the angle values for labels. I then pick the "freeze labels" tool and noticed that while it correctly populated the x/y columns then it changed the values in the rotation column to "0". This should be not be expected... or I am wrong?

#7 Updated by Larry Shaffer over 7 years ago

Giovanni,

Interesting. I had not anticipated such predefined rotation-only, though this issue certainly is concerned with that. What you are seeing is 'expected' behavior, only in that the Freeze/Thaw label tool is new and does one thing when freezing: writes the PAL solution to the mapped x, y and rotation columns.

The freezing part of the tool does not account for any preexisting, non-zero data in a field, but you can do so manually with this work around:

  1. Pre-populate your attribute table with desired horz. and vert. alignments.
  2. Before freezing, map only x and y, and optionally horz. and vert. alignments, but not the rotation column. The x and y fields will be assumed to have Null values for this.
  3. Freeze the labels. This will write data to x and y columns, but not to preexisting rotation column.
  4. Map rotation column and apply. The labels should now rotate about desired point (relative to halign and valign).

I have tested this with horizontal labels for a polygon vector layer with the following settings:

  • Placement: Over centroid
  • Horz. align: Center
  • Vert. align: Half

This resulted with labels frozen, then rotated about their middle to the data-defined value. This may in fact do what you are looking for, until rotation can be applied independent of x, y location.

I see two things that you may notice in different configurations:

  • Not pre-populating your table with horz. and vert. alignments could lead to unexpected shifting of labels to new rotation points, if you apply those settings after freezing.
  • During step # 2, if there is any rotation in the PAL solution, it will 'disappear' upon freezing and the label will rotate to 0 around your defined point, since at that stage in the workaround there is no mapped rotation column. I recommend pre-populating your table with horz. and vert. alignments to make sure it un-rotates how you want.

Please let me know if this works for you, and if not, what you particular labeling situation is - preferably by sharing some sample data.

#8 Updated by Larry Shaffer over 7 years ago

Giovanni,

Regarding your question:

"The above is quite counter-intuitive and for polygons (and also lines I guess) it can almost be considered a bug because is not clear at all what coordinates should be used to fill the "X" and "Y" columns. ..."

Unless I'm mistaken, the x, y location always refers to the rotation point of the label, whether from the PAL solution or data-defined. It has nothing to do with a feature's coordinates, excepting the fact that label placements are derived from the feature's geometry. This is one reason I made the Freeze/Thaw tool, to work directly with the label's derived location, not its feature. This is also the basis of how the other label manipulation tools work.

This means working with the horz. and vert. alignments will help you define how the label is shown, but not unless the label is data-defined (BTW, another issue, similar to independent rotation). The alignments are for the rotation point's placement relative to the actual label itself. This includes its font size and string length, which can lead to unexpected labeling changes if your label's text changes regularly and you use certain alignments.

The alignments are described here:
https://github.com/qgis/Quantum-GIS/blob/master/src/core/qgspallabeling.h#L83

Yes, there needs to be more documentation on this. :^)

#9 Updated by Giovanni Manghi over 7 years ago

Larry Shaffer wrote:

Giovanni,

Interesting. I had not anticipated such predefined rotation-only, though this issue certainly is concerned with that. What you are seeing is 'expected' behavior, only in that the Freeze/Thaw label tool is new and does one thing when freezing: writes the PAL solution to the mapped x, y and rotation columns.

The freezing part of the tool does not account for any preexisting, non-zero data in a field, but you can do so manually with this work around:

  1. Pre-populate your attribute table with desired horz. and vert. alignments.
  2. Before freezing, map only x and y, and optionally horz. and vert. alignments, but not the rotation column. The x and y fields will be assumed to have Null values for this.
  3. Freeze the labels. This will write data to x and y columns, but not to preexisting rotation column.
  4. Map rotation column and apply. The labels should now rotate about desired point (relative to halign and valign).

Hi Larry,

thanks for the extensive answer, I need to read carefully your notes but meanwhile I would answer to the above steps.

Not mapping the rotation field, freezing and then mapping the rotation field does the trick. But what about if the user mistakenly does map also the rotation field before freezing? The rotation column changes in an irreversible way (and the rotation values can take a long to be carefully computed) and so I would consider this a wrong behaviour and a "causes data corruption" issue. Do you agree?

cheers

-- Giovanni --

#10 Updated by Larry Shaffer over 7 years ago

Giovanni Manghi wrote:

... But what about if the user mistakenly does map also the rotation field before freezing? The rotation column changes in an irreversible way (and the rotation values can take a long to be carefully computed) and so I would consider this a wrong behaviour and a "causes data corruption" issue. Do you agree?

Yes. While not exactly corruption, definitely unintentional data loss, and possibly large if many labels are frozen. I think the following might work:

A) Default for unfrozen labels (NULL in x, y, and rot [rotation] fields): x, y and rot PAL engine data is frozen
B) Default for unfrozen labels with preexisting rot data (NULL in x, y fields): only x, y PAL engine data is frozen

Thawing a label is a bit more tricky since setting x, y and rot fields to NULL should be the default. Not setting the rot to NULL would mean the user couldn't set the rot field with new PAL data on a subsequent freeze because the PAL rot data would always be ignored, thereby defeating the interactivity and accuracy of the thawing feature.

It sounds like a layer-level preference along the lines of 'Clear rotation values in thawing operations' is needed. That setting, when checked, would mean any thawing operation will write NULL to the rotation field (i.e. user hasn't predefined and doesn't care about the data loss). If checked, default B) above would still be in effect to prevent accidental preexisting data loss. Now, whether that setting should, by default, be checked or not might depend upon your needs and opinion.

Do you think that's a reasonable solution? I do. And I also think the setting should default to checked, since predefined rotation values will probably be less prevalent than the desire to freeze/thaw interactively with the PAL solutions.

Example of the setting checked: a user has a predefined rotation value, then freezes the label, they will see that rotation applied. When they thaw that label, they again see the rotation is removed, allowing them to undo or not commit the change(s).

I'd like to hear other ideas, though.

#11 Updated by Giovanni Manghi over 7 years ago

Hi Larry,

Larry Shaffer wrote:

Giovanni Manghi wrote:

... But what about if the user mistakenly does map also the rotation field before freezing? The rotation column changes in an irreversible way (and the rotation values can take a long to be carefully computed) and so I would consider this a wrong behaviour and a "causes data corruption" issue. Do you agree?

Yes. While not exactly corruption, definitely unintentional data loss, and possibly large if many labels are frozen. I think the following might work:

A) Default for unfrozen labels (NULL in x, y, and rot [rotation] fields): x, y and rot PAL engine data is frozen

B) Default for unfrozen labels with preexisting rot data (NULL in x, y fields): only x, y PAL engine data is frozen

Thawing a label is a bit more tricky since setting x, y and rot fields to NULL should be the default. Not setting the rot to NULL would mean the user couldn't set the rot field with new PAL data on a subsequent freeze because the PAL rot data would always be ignored, thereby defeating the interactivity and accuracy of the thawing feature.

It sounds like a layer-level preference along the lines of 'Clear rotation values in thawing operations' is needed. That setting, when checked, would mean any thawing operation will write NULL to the rotation field (i.e. user hasn't predefined and doesn't care about the data loss). If checked, default B) above would still be in effect to prevent accidental preexisting data loss. Now, whether that setting should, by default, be checked or not might depend upon your needs and opinion.

Do you think that's a reasonable solution? I do. And I also think the setting should default to checked, since predefined rotation values will probably be less prevalent than the desire to freeze/thaw interactively with the PAL solutions.

yes it seems reasonable

Example of the setting checked: a user has a predefined rotation value, then freezes the label, they will see that rotation applied. When they thaw that label, they again see the rotation is removed, allowing them to undo or not commit the change(s).

I'd like to hear other ideas, though.

It seems to me that you already committed this changes into master, right? I will give it a try and leave feedback.

Thanks!

#12 Updated by Larry Shaffer over 7 years ago

Giovanni Manghi wrote:

It seems to me that you already committed this changes into master, right? I will give it a try and leave feedback.

Yes: 6cfb0604237244b1588c9fb66af961b1517f6c53

After some testing, I decided upon using 'Preserve existing rotation values during label freeze/thaw operations' for the PAL-layer setting and having it checked as default. Otherwise, accidental data loss was still possible, at least by the casual user who might not understand the defaults I outlined above (which aren't used now). Data loss or updates while using a tool should only be by user choice.

To make sure users who want the interactive rotation options of the freeze/thaw tool can configure it quickly, I placed the setting right under the mapping for the Rotation column in the Data-defined tab, rather than under a different tab.

#13 Updated by Giovanni Manghi over 7 years ago

  • Status changed from Open to Closed
  • Resolution set to fixed

Larry Shaffer wrote:

Giovanni Manghi wrote:

It seems to me that you already committed this changes into master, right? I will give it a try and leave feedback.

Yes: 6cfb0604237244b1588c9fb66af961b1517f6c53

After some testing, I decided upon using 'Preserve existing rotation values during label freeze/thaw operations' for the PAL-layer setting and having it checked as default. Otherwise, accidental data loss was still possible, at least by the casual user who might not understand the defaults I outlined above (which aren't used now). Data loss or updates while using a tool should only be by user choice.

To make sure users who want the interactive rotation options of the freeze/thaw tool can configure it quickly, I placed the setting right under the mapping for the Rotation column in the Data-defined tab, rather than under a different tab.

Hi Larry!
I finally tested your latest work and it seems to me that it works pretty good. I guess that we will have anyway to describe well how it works in the user manual, because I guess that a casual user will expect anyway to see the labels rotated without needing the x/y columns and without needing to pin the label. Congrats for your work!

Also available in: Atom PDF