Bug report #14036
graduated rendering: classes' upper and lower values precision truncated when saving to DOM
|Affected QGIS version:||master||Regression?:||No|
|Operating System:||Easy fix?:||No|
|Pull Request or Patch supplied:||No||Resolution:||fixed/implemented|
|Crashes QGIS or corrupts data:||No||Copied to github as #:||22049|
This one is quite odd, and can be quite tricky for users (as it will change the map symbology rendering on project re-opening).
Basically, when using the natural break classification against a field for graduated rendering, the classes' range are constantly changing every time you hit the classify button. It's a problem as whatever is causing this will silently lead do a visually different symbology output when re-opening a project. (See below for correct description of the issue)
It's slightly difficult to explain, hoping the test project attached will make it more obvious.Steps to reproduce:
- Open the attached natural_break_issue project
- Open the property window for the "communes" layer and go to the symbology panel
- Hit the "classify" button once, note how the values of classes are changing
- Hit the "classify" button again, note how the values of classes are still changing
- Hit the button again and again to see values changing seemingly randomly.
#1 Updated by Mathieu Pellerin - nIRV almost 6 years ago
- File natural_break_issue-v2.zip added
- Subject changed from graduated rendering: natural break class values change on same expression at every classification to graduated rendering: natural break class values change on field at every classification
#3 Updated by Mathieu Pellerin - nIRV almost 6 years ago
Ok, I figured out where the problem was, and opened a PR which fixes things (see https://github.com/qgis/QGIS/pull/2613).
First, TIL, the seemingly random upper and lower class values are actually by design as the natural break algorithm only takes a random sample.
Now, as for the problem: when saving the graduated symbology settings to the DOM, the code would truncate the lower and upper double values to 6 decimals, which is a problem when (as it is the case with the attached sample project) your double values have a higher precision than 6.
Take for e.g. those three values: 0.00000101, 0.00002301, 0.0000501 -- since the upper double value of the highest class would truncate to 6 decimals, 0.000050, the feature with a value of 0.0000501 would not be rendered when re-opening a project.
#7 Updated by Mathieu Pellerin - nIRV almost 6 years ago
Regis, I noticed that the natural break function will only deal with the full dataset if it has less than 1,000 features. That limit was there since this classification was added 5 years ago. I am wondering whether we should raise that limit now. CPUs have gotten much better & I feel 1,000 is unreasonably low nowadays.
Full disclosure: I have a project dealing with a dataset of about 1,600 features and I would love to have it dealt with in its entirety :)