Bug report #6640
Problem with round function of the expression builder
Status: | Closed | ||
---|---|---|---|
Priority: | Severe/Regression | ||
Assignee: | Nathan Woodrow | ||
Category: | - | ||
Affected QGIS version: | master | Regression?: | No |
Operating System: | Easy fix?: | No | |
Pull Request or Patch supplied: | No | Resolution: | |
Crashes QGIS or corrupts data: | No | Copied to github as #: | 15820 |
Description
I found a strange behavior with round function of the expression builder.
When the round is done to integer, everything seems going well. However, by introducing one or more decimal places, the results begin to be strange and often appears the default value -21474836.48.
Here ([1] , [2] , [3]) is an example with rounding areas in labels. The problem happens starting from 2 decimal places. Doing the same with the perimeter, the problem happens starting from 5 decimal places.
The data I am using are the portuguese administrative boundaries [4], but I tested it with other data and also happens.
Gioseppe Sucameli has also confirmed this problem:
-2147483648 is the min integer value, so probably the way to round number fails somewhere. I can see that each trailing '0' is removed, in addition incrementing the number of decimal places the value becomes negative: "PM" || ' ' || round( "PM", 6 ) || ' ' || round( "PM", 12 ) outputs 218317.69947 -2147.483648 -0.002147483648
I'm using QGIS master (ubuntugis unstable) on Xubuntu 12.04 and Gioseppe is using Ubuntu 11.04.
Associated revisions
History
#1 Updated by Giovanni Manghi about 12 years ago
- Target version set to Version 2.0.0
- Category deleted (
Labelling) - Status changed from Open to Feedback
- Assignee set to Nathan Woodrow
I agree with Giuseppe, that |number| is the min/max value for integers in a shapfile, so it must be something wrong with rounding.
Is this a regression? can anyone check with an older release?
Please note that there is another ticket asking to add a warning anytime for some reason the length limit of shapes fields is passed, in order to avoid have users guess why their columns are filled with strange values. If possible add your note there also.
I'm giving this ticket to Nathan because he worked lately in the expression builder, but I don't know if he is the right person anyway. Nathan in case just remove your name.
#2 Updated by Nathan Woodrow about 12 years ago
That's cool you can leave it assigned to me.
It's not a regression as I only added this function after 1.8.
#3 Updated by Alister Hood almost 12 years ago
The status for this ticket probably shouldn't be "Feedback".
#4 Updated by Giovanni Manghi almost 12 years ago
- Status changed from Feedback to Open
#5 Updated by Anita Graser over 11 years ago
- Priority changed from Normal to High
I think this bug is much more important. Testing Select by expression, I ran into the following odd situation: I'm
using the lakes.shp from the QGIS sample data and the following two expressions return different results:
$area > 28386358480
selects all lakes, even though only one is that big
$area > 28386358480.0
returns the correct result and only one lake is selected.
http://lists.osgeo.org/pipermail/qgis-user/2013-April/021907.html
This should really be fixed for 2.0.
#6 Updated by Jürgen Fischer over 11 years ago
- Priority changed from High to Severe/Regression
#7 Updated by Jürgen Fischer over 11 years ago
- Status changed from Open to Closed
Fixed in changeset eeebf5bd17b4cd8a10707dda6b32966659ca28d0.