Feature request #11338

field calculator: if you choose 'double' as fieldtype, the precision is NOT set to >0

Added by Richard Duivenvoorde about 10 years ago. Updated about 7 years ago.

Status:Open
Priority:Normal
Assignee:-
Category:Unknown
Pull Request or Patch supplied:No Resolution:
Easy fix?:No Copied to github as #:19632

Description

After a question on IRC of somebody who ended up with area's of 0

Load the shp from test.zip (epsg:28992)
Make layer editable
Open Field Calculator
Tick 'create a new field' and fieldname 'area' and fieldtype double (but do not touch the precision which in my case is 0 then)
Now create the column with value $area

then the area looks ok
but after saving all numbers are/look integers....

REMARK: changed from bug to feature request.

After some testing it appeared that the precision in the dialog was on 0 (zero)
so the actual were doubles, but without precision (25.1233 became 25).

So feature request: IF the user chooses 'double' as fieldtype and the precision = zero,
then either let it know (because a double with zero precision is not a double) and warn the user,
OR set the precision on 5 or so

also it's not fully clear if the 'precision' includes the output fieldwidth or not,
from IRC: "i set the precision to 10, saves 8, i set to 11 saves with 9 precision"

test.zip (3.59 KB) Richard Duivenvoorde, 2014-10-06 03:32 AM

History

#1 Updated by Matthias Kuhn about 10 years ago

Just to be sure I understand correct. This feature request is:

  • Change the default precision for double to 5 instead of 0
  • Write a hint that the precision does not only affect decimals

#2 Updated by Richard Duivenvoorde about 10 years ago

I think this is actually the same one as: #9142

#3 Updated by Richard Duivenvoorde about 10 years ago

@mkuhn: Change the default precision for double to 5 instead of 0

So the Output field width should change to sensible defaults when you change the type.

as you see in #9142 also it is a caveat when you do not look at the precision...

Now if you change from double to int, it sets the precision to 0, but the other way around it does NOT set it back or to an other sensible value for double.
Same with text, I would think that maybe 30 is more sensible width then 10?

#4 Updated by Giovanni Manghi over 7 years ago

  • Easy fix? set to No

#5 Updated by Jürgen Fischer about 7 years ago

  • Category set to Unknown

Also available in: Atom PDF