QGIS » QGIS Application

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.

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.

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?

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.

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. :^)

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 --

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.

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!

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.