Bug report #7217
graduated classes are altered when saved to qgs
Status: | Closed | ||
---|---|---|---|
Priority: | Severe/Regression | ||
Assignee: | - | ||
Category: | Symbology | ||
Affected QGIS version: | master | Regression?: | No |
Operating System: | Easy fix?: | No | |
Pull Request or Patch supplied: | Yes | Resolution: | worksforme |
Crashes QGIS or corrupts data: | No | Copied to github as #: | 16253 |
Description
confirmed on both 1.8 and master dc074b3.
when classifying continuous numerical data (shp - field type; real ; length 20; precision 5) , classes are generated correctly, but are saved with exponents notation if data exceeds 1000000:
In the following example, the last classe upper value has been converted from 6 034 292 to 6.03429e+06.
real max value is then thrown out of classes because 6.03429e+06 is converted to 6 034 29*0* when project is reloaded.
All the values close to upper and lower bounds are potentially concerned.
This is a blocker since there is no way to save a project correctly, except modifying classes by hand in a text editor.
-----
<renderer-v2 attr="PTBRUTTOT" symbollevels="0" type="graduatedSymbol">
<ranges>
<range symbol="0" lower="0" upper="84191.1" label="0 - 84 192"/>
<range symbol="1" lower="84191.1" upper="329134" label="84 192 - 329 134"/>
<range symbol="2" lower="329134" upper="797510" label="329 134 - 797 511"/>
<range symbol="3" lower="797510" upper="1.25838e+06" label="797 511 - 1 258 384"/>
<range symbol="4" lower="1.25838e+06" upper="6.03429e+06" label="1 258 384 - 6 034 292"/>
</ranges>
Associated revisions
History
#1 Updated by Regis Haubourg over 11 years ago
QML and mapinfo tab are also concerned
#2 Updated by Regis Haubourg over 11 years ago
It could be simple to solve since same problem occured with WMS bounds and scales:
here are some revisions solving thoses problems: [[https://issues.qgis.org/search/index/quantum-gis?q=exponential]]
#3 Updated by Regis Haubourg over 11 years ago
conversion to Double seems to be done here:
[[https://github.com/qgis/Quantum-GIS/blob/master/src/core/symbology-ng/qgsgraduatedsymbolrendererv2.cpp]]
line 888:
double lowerValue = rangeElem.attribute( "lower" ).toDouble();
double upperValue = rangeElem.attribute( "upper" ).toDouble();
use of .toDouble seems to be done everywhere. Any idea ?
#4 Updated by Alexander Bruy over 11 years ago
- Pull Request or Patch supplied changed from No to Yes
- File fix_7217.patch added
- Category changed from Map Legend to 83
Here is patch that should fix such issue. Unfortunately, I can't test it with wide range of datasets, so maybe in some cases it still don't work as expected.
#5 Updated by Regis Haubourg over 11 years ago
Hi, a little up to commiters: Can anyone test before merge ? This might be a easy-to-solve blocker ;-)
(I can't compile by myself and can only test ith osge4w).
Régis
#6 Updated by Nathan Woodrow over 11 years ago
Can we confirm if this still and issue. I can't reproduce here.
#7 Updated by Mathieu Pellerin - nIRV over 11 years ago
I can't reproduce this issue either. So what they say is true, time does heal ;o)
#8 Updated by Nathan Woodrow over 11 years ago
- Resolution set to worksforme
- Status changed from Open to Closed
Regis can you test with the latest build and report back if it is still an issue.
#9 Updated by Regis Haubourg over 11 years ago
Hi, there is no new build on osgeo4w today, I'll try next week (QGIS training by the end of the week!)
#10 Updated by Regis Haubourg over 11 years ago
- File Grauated_classes_test_sample.zip added
- Status changed from Closed to Reopened
Hi,
I must reopen, tested in e2bd04f today, problem is still here, qgs is still saved using scientific notation.
see:
<ranges>
<range symbol="0" lower="1" upper="3" label="1.0000 - 3.0000"/>
<range symbol="1" lower="3" upper="56" label="3.0000 - 56.0000"/>
<range symbol="2" lower="56" upper="1e+09" label="56.0000 - 1000000389.0000"/>
</ranges>
I join a very simple dataset to build unit tests:
#11 Updated by Nathan Woodrow over 11 years ago
Ok I see it. Will try and fix.
#12 Updated by Minoru Akagi over 11 years ago
QVariant::toString() seems to return better results than QString::number(), doesn't it?
In python:
>>> from PyQt4.QtCore import * >>> val = 6034292. >>> QString.number(val) PyQt4.QtCore.QString(u'6.03429e+06') >>> QVariant(val).toString() PyQt4.QtCore.QString(u'6034292') >>> val = 1.000001 >>> QString.number(val) PyQt4.QtCore.QString(u'1') >>> QVariant(val).toString() PyQt4.QtCore.QString(u'1.000001')
#13 Updated by Nathan Woodrow over 11 years ago
Seems so.
toString is the way to go.
#14 Updated by Jürgen Fischer over 11 years ago
- Status changed from Reopened to Closed
Fixed in changeset 4538cf1593a22c1aba998abfc6f3c730b0943a71.