Bug report #9690
Incorrect areas using field calculator.
|Affected QGIS version:||2.0.1||Regression?:||No|
|Operating System:||Easy fix?:||No|
|Pull Request or Patch supplied:||No||Resolution:||duplicate|
|Crashes QGIS or corrupts data:||No||Copied to github as #:||18255|
This was using QGIS 2.01 in Windows 7.
I had a project containing several shape files (and an Openlayers plugin layer, which was switched off). The shapefiles were all in projection 32721 WGS84/UTM21S, as was the project (I must switched this back to 32721 manually after switching off the Openlayers plugin layer). On-the-fly re-projection was enabled.
I used the field calculator to generate a new field to calculate the areas of the polygons in one of the shapefiles. The areas calculations were wrong. Extremely large, many 0s and many negative values. I was using a large decimal field(20,1) and was aiming to calculate in hectares (maximum polygon size should have been 2-3000 hectares). I checked the validity of the geometry and corrected any errors, but this had no effect.
I worked around the problem by creating a new project and importing just the shapefile that I wanted to calculate the area on and the field calculator calculated the area with no problems. It would appear to be an issue related to the projection, and possibly to Openlayers plugin automatically flicking the project projection when adding layers, and then me manually changing it back.
I think this bug is quite serious. In this instance the errors where large and easy to spot but that might not have been the case. It is easy for a human to look at spatial data and determine serious errors, but not so easy to spot them in tables of attribute values, and a level of trust in the software to get those values right is needed. Calculation of area must also be one of the most common outputs from a GIS.
#3 Updated by Giovanni Manghi about 6 years ago
- Affected QGIS version changed from 2.2.0 to 2.0.1
Thomas McAdam wrote:
Sorry should have been 2.01 for affected version. I will have a go at recreating the error in 2.2 and report back.
Please notice that with reprojection active the area/length computing is now affected by the ellipsoid you have defined in the project properties (wgs84 by default, but you can choose also "planimetric/none").
#4 Updated by Thomas McAdam about 6 years ago
I am able to recreate the bug in 2.2 as well, although it's characteristics are slightly different. In the screengrab qgis_error3.jpg.
Fields area_m and area_ha were calculated in 2.01 with the shape file being the only file in the project.
Fields area_m1 and area_ha2 were calculated in 2.2 in a project with a switched off Openlayers layer and the CRS changed back to 32721. You see there is a small error in all values. There was a also large error in some polygons and 1 negative (screengrab qgis_error1.jpg).
Fields area_m2 and area_ha2 were calculated in the same circumstances as area_m and area_h2, but in 2.2 rather 2.01 and seem to be giving correct values.
#6 Updated by Giovanni Manghi about 6 years ago
- Resolution set to duplicate
- Status changed from Feedback to Closed
Thomas McAdam wrote:
LAst line has a mistake, should read:
Fields area_m2 and area_ha2 were calculated in the same circumstances as area_m and area_h, but in 2.2 rather 2.01 and seem to be giving correct values.
In qgis 2.0.1 there was an issue when computing area/lengths when OTFR was on. This was fixed.
In QGSIS 2.* there is anyway a change when computing area/lengths: if OTFR is ON (regardless if you are reprojecting a layer or not) then the ellipsoid (be default wgs84) is taken into account and measures change slightly.
You can change the ellipsoid in project properties, and set it to "plane/none" and get always the results as if OTFR is off.
So this is duplicate of #9060
that by the way we should close in favuor of a new ticket that should address this change (since 1.8) in a better way for the user.