Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

area calculation in Field Calculator is depending on Output field type #22092

Closed
qgib opened this issue Jan 10, 2016 · 5 comments
Closed

area calculation in Field Calculator is depending on Output field type #22092

qgib opened this issue Jan 10, 2016 · 5 comments
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Vectors Related to general vector layer handling (not specific data formats)
Milestone

Comments

@qgib
Copy link
Contributor

qgib commented Jan 10, 2016

Author Name: Richard Duivenvoorde (@rduivenvoorde)
Original Redmine Issue: 14082
Affected QGIS version: master
Redmine category:vectors


Not sure how much this is related to #21270

But when I use the Field calculator to create a virtual field with the area of some polygons, my first try resulted in 80% NULL values.
On further testing the results seem ok. Only difference I did was changing the Output field type from Whole number (integer) to Decimal number (real)

To test, (see screendump for output with both options)

  • open attached shp file with the 12 provinces of The Netherlands
  • set project crs to epsg:28992 + OTF, and data crs is also epsg:28992 (Amersfoort)
  • now open the Field calculator and create a new field / create virtual field and call it 'area'
  • as Expression use $area
  • click OK: as you can see only 3 polygons have an area value, rest has NULL
  • now open the Field calculator again and create a new field / create virtual field and call it 'area2'
  • BUT change the default output fieldtype to Decimal !!
  • as Expression use $area
  • click OK: now all provinces have an area value!

?? what goes wrong here. Or at least how should a normal user find out this behaviour?

Maybe after fixing, also change the default value of output to Real/Float?



Related issue(s): #20739 (relates), #21270 (relates)
Redmine related issue(s): 12622, 13209


@qgib
Copy link
Contributor Author

qgib commented Jan 11, 2016

Author Name: Richard Duivenvoorde (@rduivenvoorde)


Update: I found out that it is apparently a integer overflow problem. That is, only the 3 smallest provinces have a value...

And if I change the expression to $area/(1000*1000) (so from meters to square km), all give a valid result EVEN when I set the output type to integers. Off course because then the values are smaller.

But I also checked the error messages, but did not see anything.

Proposal:

  • give a clear/descent error message when a integer overflow takes place during calculation (popup?)
  • make floats the default when you create an expression (or text), so this problem does not occur for innocent users like me :-)

@qgib
Copy link
Contributor Author

qgib commented Jan 12, 2016

Author Name: Giovanni Manghi (@gioman)


Hi Richard,
related also to #20739 ?


  • status_id was changed from Open to Feedback

@qgib
Copy link
Contributor Author

qgib commented May 23, 2016

Author Name: Giovanni Manghi (@gioman)


It is still true on the latest master and from what I see is not only related to virtual fields.


  • status_id was changed from Feedback to Open
  • category_id was changed from Virtual Fields to Vectors

@qgib
Copy link
Contributor Author

qgib commented Apr 30, 2017

Author Name: Giovanni Manghi (@gioman)


  • easy_fix was configured as 0
  • regression was configured as 0

@qgib
Copy link
Contributor Author

qgib commented Mar 9, 2019

Author Name: Giovanni Manghi (@gioman)


End of life notice: QGIS 2.18 LTR

Source:
http://blog.qgis.org/2019/03/09/end-of-life-notice-qgis-2-18-ltr/


  • resolution was changed from to end of life
  • status_id was changed from Open to Closed

@qgib qgib closed this as completed Mar 9, 2019
@qgib qgib added Bug Either a bug report, or a bug fix. Let's hope for the latter! Vectors Related to general vector layer handling (not specific data formats) labels May 25, 2019
@qgib qgib added this to the Version 2.14 milestone May 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Vectors Related to general vector layer handling (not specific data formats)
Projects
None yet
Development

No branches or pull requests

1 participant