Bug report #17102
Editing raster pseudocolor classification seems to trigger unwanted auto-classification after validation and by the same clearing all modifications
| Status: | Closed | ||
|---|---|---|---|
| Priority: | High | ||
| Assignee: |  Mathieu Pellerin - nIRV | ||
| Category: | Symbology | ||
| Affected QGIS version: | master | Regression?: | Yes |
| Operating System: | Easy fix?: | No | |
| Pull Request or Patch supplied: | Yes | Resolution: | fixed/implemented |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 25001 |
Description
Process to reproduce the issue :
load an one-band raster, open layer properties, create a new pseudocolor classification and then press ok on the other hand, the following modifications are properly applied
-reopen the properties, try to modify the classification (value, color or add/remove step) and then press apply >> the modifications are not taken into account and the classification reverts back to its initial state.
The issue concerns only QGIS master and happen both on properties window and style panel.
Associated revisions
[raster] don't auto-classify upon customizing values tree (fixes #17102)
History
#1
Updated by Giovanni Manghi about 7 years ago
- Regression? changed from No to Yes
#2
Updated by Nyall Dawson almost 7 years ago
- Status changed from Open to Feedback
Can't reproduce - is this still an issue? If so, please post step-by-step instructions on reproducing (or a video)
#3
Updated by Dominique Lyszczarz almost 7 years ago
- File qgis bug report 17102.jpg added
I can't replicate the bug in the layer's properties dialog but it still occur in the style panel. In attachment a screenshoot that illustrate the problem.
It seems it happen only after selected another layer and then come back to edit the classification, for example:
- load a raster and create a simple classification
- duplicate the layer and select the new unchecked layer
- now trying to edit the classification of this layer and here the problem occurs
#4
Updated by Dominique Lyszczarz almost 7 years ago
Please find in attachment a test file containing a raster classification. Trying to edit this classification or even change color settings like brightness, completely mess up the classification.
#5
Updated by Mathieu Pellerin - nIRV almost 7 years ago
I'll have a look at this. It's not a bug per say but we might have to tweak the UX a bit. Right now, modifying classes automatically reclassify the renderer.
#6
Updated by Dominique Lyszczarz almost 7 years ago
- Status changed from Feedback to Open
Thanks Mathieu, now that's it's confirmed I change the statut. Not sure about the bug definition but this is an unwanted behaviour in the ui mecanism and this is a very anyoning problem making raster styling pretty unsuable in day by day tasks. Workaround is to save the colormap to an external txt file and then reload it after classification messup.
#7
Updated by Mathieu Pellerin - nIRV almost 7 years ago
- Assignee set to Mathieu Pellerin - nIRV
- Pull Request or Patch supplied changed from No to Yes
#8
Updated by Mathieu Pellerin - nIRV almost 7 years ago
- % Done changed from 0 to 100
- Status changed from Open to Closed
Applied in changeset qgis|51c5805e13db55a30802ec49fe3313b27d832ee5.
#9
Updated by Dominique Lyszczarz almost 7 years ago
- Status changed from Closed to Reopened
Thanks for the fix but unexepected auto-classification still occurs after:
- changing color interpolation mode
- autocompute min max stats
- editing the color of a class
- editing label of a class
- changing layer rendering options like blending mode, brightness, saturation, contrast ...
- changing resampling options
It seems to me that classification should happen only and only if the user explicitly click on the classify button, this auto-classification mecanism is really disturbing and unexepected.
#10
Updated by Dominique Lyszczarz almost 7 years ago
Note that this auto-classification only occurs at the first edit of any style option
#11
Updated by Mathieu Pellerin - nIRV almost 7 years ago
- Status changed from Reopened to Closed
- Resolution set to fixed/implemented
Dominique,
OK, I've pushed a follow up commit to fix what I consider is the last remaining issue here, whereas colors changed through the tree widget could be overwritten.
As for the other raised issues, I think it might actually be desired behavior in most cases :) for e.g, yes, auto-computing min/max should trigger a classification. I can't reproduce the interpolation, blending, etc. issue here.
Thanks for raising this auto-classification issue to begin with.
I'll close this now, please open new ticket(s) with steps to reproduce if you still hit some problems that's not directly related to editing of the classification via the tree widget. Thanks.
#12
Updated by Dominique Lyszczarz almost 7 years ago
Thank you very much Mathieu for your help, I'll try this in the next days.
#13
Updated by Alister Hood almost 7 years ago
- File after apply.JPG added
- File after load style before apply.JPG added
Hi guys, I still have a problem. I'm not sure if you want me to file this in a different ticket - rather than being "directly related to editing the classification via the tree widget", it is about loading a style file that was produced by editing the classification:
I get unwanted classification after doing "load style" when I click "OK" or "Apply" (in the main layer properties dialog). See the screenshots attached.
I don't know that I can test this in the style panel - I can't see a "load style" option there.
I think that if the intended behaviour is to always autoclassify, then there needs to be another classification mode called "manual".
#14
Updated by Alister Hood almost 7 years ago
- Status changed from Closed to Reopened
#15
Updated by Mathieu Pellerin - nIRV almost 7 years ago
Alister, have you tried saving a style from a current build and loading that? That shouldn't cause unwanted auto classification. If the style is from QGIS 2.X, that s a different story.
#16
Updated by Alister Hood almost 7 years ago
Thanks Mathieu - yes, that solves the problem, and at least in my case the style files are backwards compatible.
I only have 3 styles, so it isn't a problem for me to recreate them, but I imagine if this is necessary in the final QGIS 3 release it could be quite painful for some people, and should probably be documented prominently as a "known issue". Is it not possible to avoid?
#17
Updated by Mathieu Pellerin - nIRV almost 7 years ago
- Status changed from Reopened to Closed
Alister, glad to hear it works. Regarding the 2.X style imperfection, I don't intent to work on that. Feel free to file an issue, although I'm not sure it'd be worth the energy ;-P
#18
Updated by Alister Hood almost 7 years ago
I don't think another ticket is necessary unless someone is likely to work on it.
I've noticed a related issue though.
Regardless of the "render type" (I first noticed it using "hillshade"), when you load a style using the "layer properties" dialog it initially renders using the zoomed in and out resampling options from the qml file, but the settings displayed in the dialog remain the same as they were before you loaded the style. Then when you click "apply" it is re-rendered with the settings from the dialog.
Shall I file another ticket for this?
#19
Updated by Alister Hood almost 7 years ago
Also note that there is a similar long-standing issue with unwanted raster stretching: (3) at #4160
#20
Updated by Alister Hood almost 7 years ago
Alister Hood wrote:
I don't think another ticket is necessary unless someone is likely to work on it.
I've noticed a related issue though.
Regardless of the "render type" (I first noticed it using "hillshade"), when you load a style using the "layer properties" dialog it initially renders using the zoomed in and out resampling options from the qml file, but the settings displayed in the dialog remain the same as they were before you loaded the style. Then when you click "apply" it is re-rendered with the settings from the dialog.
Shall I file another ticket for this?
Filed as #18153