Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix various issues with application of raster styles from QML-files #38082

Closed
wants to merge 4 commits into from

Conversation

iona5
Copy link
Contributor

@iona5 iona5 commented Aug 1, 2020

Description

This PR fixes various issues with the application of styles from QML-files to raster layers. The general behavior is that a style is loaded from a QML with a colormap. Then this style seems to be show up OK in the canvas, but the actual color map assignment is sometimes wrong, and when you hit apply a wrong style is actually applied or the color scheme reverts back to a default one.

An example of this behavior (using ESACCI-LC data from http://maps.elie.ucl.ac.be/CCI/viewer/download.php)

rasterstyle_issue

This behavior is described in issues

Two major reasons for this behavior are probably the culprits:

applying a color ramp overwrites an already set colormap

When the QgsColorRampShaderwidget is populated by data from a QgsColorRampShader, the colormapTreeWidget is filled first (containing specific value->color assignments). After that it is checked if the shader has a colorramp and if it has none the default colorramp is applied. The problem is that this in the end emits colorRampChanged() which in turn repopulates the colorrampTreeWidget with new colors from the set colorramp (in this case the default one) overwriting the ones from the applied shader.

Fix: populate the colormap after the color ramp is applied. (7368e7f)

QgsColorRampShaderWidget::applyColorRamp() relies on valid mMin and mMax

A second problem is that the function QgsColorRampShaderWidget::applyColorRamp() assumes that the member variables mMin and mMax are already set when calculating new colors for the colormap. This is not necessarily the case as when a QgsSingleBandPseudoColorRendererWidget is populated by a QgsSingleBandPseudoColorRenderer the min/max form fields are set after the color ramp shader is applied. Then the colors for all the entries in the colormap are picked with a nan-value.

Fix:

  • populate the min/and max fields in QgsSingleBandPseudoColorRendererWidget before applying the color ramp (5b81714)
  • to prevent future problems with unset mMin/mMax in QgsColorRampShaderWidget, as a fallback the color map is created by the min and max values of the actual values in the color map if mMin or mMax are nan (914f719)

This PR fixes #28229, #28926 and #29427 and may also fix #26701.

When applying a style file with a colorrampshader node but without
a colorramp node, the actual color values of the items of the ramp
are overwritten by the default ramp (currently 'Spectral'). Files
with not colorramp node happened to be created by earlier QGIS
versions - at least with 2.10.

This is because the default ramp is applied after populating the
color ramp item list. Applying a color ramp emits a
colorRampChanged() signal. This signal causes new colors from the
ramp applied to the items, overwriting the already set ones.

This is not desired. Fix by populating the item list after applying
the color ramp.
…derer

When populating QgsSingleBandPseudoColorRenderer from an existing one the
min/max values where set last. However if that renderers shader was a
QgsColorRampShader without an actual color ramp, a default one was used.
Now, if the color ramp shader contained a color map, we try to interpolate
the colors with these min/max values, which are not set yet.

So we set these values before loading any raster shader.
if mMin or mMax are not set yet for some reason, we should try our
best to apply a reasonable color ramp.
@github-actions github-actions bot added this to the 3.16.0 milestone Aug 1, 2020
@iona5 iona5 closed this Aug 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant