QGIS » QGIS Application

Please test with current master, this may have been fixed along with #13601

I'm reading through All of this and I have a practical example:

Attached is a shapefile in EPSG:2240. There is an area field added. Calculate the area with OTF on and OTF off using the field calculator. The results are wildly varying. Converting the results to Acres gives me 4.7(ish) with OTF on and 50.5 with OTF off. The area is 50.5 acres (or 2200346 square feet). This has been an on going problem on my end starting at 2.4 or 2.6. It's not ellipsoidal. I haven't tested this on windows - I'm on Ubuntu 14.04.3 2.10 QGIS.

It seems like it's returning almost sq meters although the projection is in US Feet. Which almost maybe the ellipsoidal issue mentioned.

Anyway - I always hope this is just me - but if it is - possibly more of an indication of insanity. I don' tthink it is - but I will never rule out insanity.

Hmmm... I can't work out what the expected behaviour is here, and have run out of time for 2.12 fixes.

It seems to me that in QGIS master things are ok. There is just still an issue with virtual fields

#12622

Giovanni,
I am still getting the same behaviour when calculating a non-virtual field with 2.13-16.

Mathieu,
That seems to be the case(with OTF on $area is calculated in square meters) for MOST of the features in the dataset I am testing but there are a few(11 out of 638) where the areas are WAY off. For all features the areas are calculated correctly when OTF is off and also with OTF on and the ellipsoid is set to non/planimetric. but with OTF on and the default ellipsoid I get bad values, for instance:

correct area(m2) calculated area(m2)
9,213 12,829,041
13,437 3,686,013
140,552 16,559,293
855,174 559,466

The steps I took were:
field calculator button
new field, integer = $area

Im attaching the shapefile I am using to test this with several test fields calculated so you can see the values I am getting.

Andrew McAninch wrote:

Giovanni,
I am still getting the same behaviour when calculating a non-virtual field with 2.13-16.

JC, I see... To be more clear I attached here your dataset but in 3857, to units are meters (because we know there is also the issue of QGIS computing always in meters even if the CRS is in feet). I left 3 columns, area by postgis, area by qgis no OTF, area by qgis with OTF. I have tested also other desktop gis packages and the results are correct.

The problems noted in this ticket (and some others related to it) interested me as I had been considering how to go about testing QGIS. This seemed to be an excellent opportunity to refine some procedures and hopefully define the problems coherently.

I have concentrated on the data in area_test for my testing. One thing I noticed in this data is that the various calculated areas are integer values. This made it hard to spot small differences, so I have used floating point storage for my testing.

And I got curious about what happens if the geometries are changed -- moving or altering the shape.

I transformed area_test from EPSG:2285 to EPSG:32148 to have the data in the same basic projection, but with meters for units. This is easily done with PostGIS or SpatiaLite using DB Manager to import/export.
I considered that transforming to EPSG:3857, as some have done, throws in complications for finding the root cause of the problems.

The 10000sqft-test-2285 file was created to have a very specific known area for some tests.

Note that in the procedures below, when I indicate "OTF on" this means only checking "Enable 'on the fly' CRS transformation" in Project Properties and accepting the ellipsoid that the CRS uses, in this case, GRS 1980. I did not test the effect of using different ellipsoids.

Not mentioned before, but there is another function that calculates area: area() -- more specifically, area($geometry) would appear to be equal to $area (which it isn't.)
I'm not sure whether area() is strictly plane or can handle ellipsoidal calculations.

Also not mentioned is any possible effect of "Preferred units" in Settings|Options|Map Tools, so I have tested this. The only effect I saw was in Identify Results.

I haven't included much on what Identify Results, Derived Area shows, but generally it does show the same area as calculated by $area, but the value is rounded so it is hard to be sure.

Based on testing I conducted:

A. when OTF is on, the $area calculation has a problem with geometries. Specifically, the area calculation based on an ellipsoid is defective. A few geometries in the provided area_test file are very obviously incorrect, but all aren't really close to what they should be.

B. two different area calculations are used: one for $area; a different one for area($geometry) -- the results are very slightly different for planar area calculation. This is not obvious on geometries that have whole numbers for vertex x, y values and have regular shapes like rectangles.

This leads to confusion because of the very slightly different results.

C. from running some PostGIS queries, I believe that all of the QGIS area computations on area_test using $area with OTF on are likely incorrect by a significant amount. The area computed based on ellipsoid should be within less than 0.1% of the value in sqm_arc field, I should think, as the CRS is a State Plane Coordinates projection.

D. the Field calculator has confusing behavior on actual field vs. virtual field
1. Field Calculator: the $area value placed in a virtual field uses the planar area value instead of the area based on ellipsoid; this is unexpected
2. Field Calculator: the $area value placed in an actual field is the area based on ellipsoid in meters

E. when OTF is on, in Expression Builder, for a virtual field, the preview value for $area varies with whether the builder is used to create the field or is editing an existing field. This is very confusing.

----
data showing the above points:
[using QGIS dev 5b59609]

• area_test feature ID=301/sqft_arc=144636: $area = 144636.18460 sq ft (OTF off) and 5626033.17938 (OTF on)

• changing the shape of specific objects -- does not appreciably change the area calculated IF the area was way off.
• moving specific objects -- changes the area calculated IF the area calc was way off

• tested the calculated area: OTF to non-OTF and found that all features were different by about 0.1% or more; at first, this seemed reasonable (except for a few large differences), but on reconsideration I would expect a smaller difference as the CRS is a State Plane Coordinates projection (see PostGIS test below)
  I tested both area_test and area_test transformed to EPSG:32148 Washington N in meters, with similar results for both
  

  ------------
  testing the percent change of QGIS calculated area: OTF area to non-OTF area
  Using Field Calculator create the following fields/expressions on the sample data (use type double, 19 / 10 ):
  
  actual field: area_noOTF    $area *((1200.0/3937.0)^2)    (NOTE: turn off OTF first; convert to sq m -- don't need to convert if units is m)
  actual field: area_OTF        $area                (NOTE: turn on OTF first)
  virtual or actual field: pct_chg    ("area_OTF"/("area_noOTF")*100)-100 
  
  ------------
  

B. example: for the area_test feature with sqft_arc=144636: $area=144636.18460083, area($geometry)=144636.18456012; from PostGIS: st_area()=144636.18456012, which is the same as area($geometry)

C. after importing area_test to PostGIS I ran ran some area computations; following is the query I used to compare the area determined from geography type (WGS84 ellipsoid) to the area of the original plane projection geometry type. Note that geography type is limited to the WGS84 ellipsoid, but has no significant difference compared to GRS80.

------------
-- PostGIS 2.1  to get area in various CRS (SRS in PostGIS parlance); compare 2 particular results
select id, area_2285_m, area_32148, area_26910, area_4326_geog,
    ( area_4326_geog / area_2285_m * 100 ) - 100 as pct_chg    -- compare geography area (sq m) to cartesian area (sq ft conv. to sq m)
from 
(
    select id, 
        st_area(geom) * ((1200.0/3937.0)^2) as area_2285_m,    -- Washington N, ft; planar ft->m
        st_area(st_transform(geom,32148)) as area_32148,    -- Washington N, m; planar
        st_area(st_transform(geom,26910)) as area_26910,    -- UTM zone 10; planar
        st_area(st_transform(geom,4326)::geography) as area_4326_geog    -- ellipsoid, m
    from test_data.area_test
) x
order by id;
------------

Note that State Plane Coordinates (2285 & 32148) are intended to be accurate to about 1 part in 10000 for position, as I understand it. Area accuracy would be somewhat less.

As I don't know what the accuracy of the PostGIS (Proj4 and GEOS internally) functions are, I believe the PostGIS computed areas to be reasonable.

Projections like UTM cover large areas so they tend to be less accurate.

D. 1. & D. 2. see Excel worksheet: QGIS-#13209-testing-results.xlsx
this shows changing three variables and noting the results for the 10000sqft test files

E. observe: on virtual field creation, for $area the preview value is the calculated ellipsoid value in meters; on editing the expression the preview is the planar value in layer units.

I have chosen not to include the results as anyone should be able to reproduce the results from the procedures provided. I have noted the specific QGIS development version I used as a different one may produce different results, depending on what has been changed.

I am including an Excel worksheet showing the results for point D. as it is rather tedious to construct.

And I am also including the two files used for point D. containing a 10000ft x 1ft test object in CRS EPSG:2285 and EPSG:32148
10000sqft-test.zip containing: 10000sqft-test-2285.shp and 10000sqft-test-32148.shp

• the ellipsoidal area calculation used by $area and Identify (most important!)
• for plane area calculation $area should be equal to area($geometry)
• the logic of Field Calculator as to how $area is calculated and shown as well as stored in a field (actual vs. virtual) should be consistent

With 479d90a5ceec1c1b658aa101702ecf855e534987 this should now be resolved, with the one exception of virtual fields (#12622).

I'd appreciate extensive testing and feedback so that we can get this closed before 2.14 is released.