https://issues.qgis.org/https://issues.qgis.org/favicon.ico2015-10-09T13:53:00ZQGIS Issue TrackingQGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=643182015-10-09T13:53:00ZJohn Tull
<ul></ul><p>I can confirm that this bug exists in trunk as well. With OTF on, area calculations are many orders of magnitude off for data in a UTM meters coordinate system. Areas are accurately calculated when OTF is turned off.</p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=643772015-10-10T05:20:48ZRandal Halerjhale@northrivergeographic.com
<ul></ul><p>There are several of these bug reports floating around <a class="issue tracker-1 status-5 priority-5 priority- closed" href="https://issues.qgis.org/issues/9690" title="Incorrect areas using field calculator. (Closed)">#9690</a> -> this is one that is I think still open.</p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=643782015-10-10T05:21:39ZRandal Halerjhale@northrivergeographic.com
<ul><li><strong>Target version</strong> set to <i>Version 2.12</i></li></ul> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=643792015-10-10T05:22:51ZRandal Halerjhale@northrivergeographic.com
<ul></ul><p>I followed <a class="issue tracker-1 status-5 priority-5 priority- closed" href="https://issues.qgis.org/issues/9690" title="Incorrect areas using field calculator. (Closed)">#9690</a> and it's still incorrect - although in Master (2.11) area gets set to 0. Which is slightly better than something that looks slightly right.</p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=643802015-10-10T05:32:13ZRandal Halerjhale@northrivergeographic.com
<ul></ul><p>Seems to also be related to this one that is closed <a class="issue tracker-1 status-5 priority-10 priority- closed" href="https://issues.qgis.org/issues/12057" title="Computed area is wrong when reprojection is active (Closed)">#12057</a></p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=646002015-10-14T22:49:30ZNyall Dawson
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Feedback</i></li></ul><p>Please test with current master, this may have been fixed along with <a class="issue tracker-1 status-5 priority-10 priority- closed" href="https://issues.qgis.org/issues/13601" title="error calculating area for polygons when otf reprojection is on and the CRS is Indian 1960 48N (Closed)">#13601</a></p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=646272015-10-15T09:31:42ZAndrew McAninch
<ul></ul><p>I just tested with the latest OSGEO4W nightly(2.11.0-88) and I get the same errors.</p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=646292015-10-15T10:21:14ZNyall Dawson
<ul></ul><p>You'll need the next build, that one is too early</p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=646662015-10-16T08:58:14ZAndrew McAninch
<ul></ul><p>I updated to 2.11.0-89 and the bug is not completely fixed. Now if OTF is on and the ellipsoid is set the "None/Planimetric" the areas are calculated correctly. However, if OTF is on and I leave the ellipsoid set to the default then the values are wrong.</p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=646702015-10-16T16:12:12ZNyall Dawson
<ul><li><strong>Assignee</strong> set to <i>Nyall Dawson</i></li></ul> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=646712015-10-16T19:31:10ZNyall Dawson
<ul></ul><p>Hmm... I can't reproduce this, using the attached dataset and described steps. Here's what I see:</p>
<p>For the feature which sqft_arc = '142434'<br />- OTF OFF: area = 1.323 ha<br />- OTF ON, EPSG 2285, default ellipsoid (GRS 1980): area = 1.322 ha<br />- OTF ON, EPSG 2285, ellipsoid = none/planimetric: area = 1.323 ha<br />- OTF ON, EPSG 4326, ellipsoid = WGS84: area = 1.322 ha</p>
<p>All looks OK to me. This is using the identify tool and looking at the derived area attribute. What method are you using to determine the area?</p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=646732015-10-17T03:17:16ZAndrew McAninch
<ul></ul><p>I should have specified that I am using the field calculator. I tested the identify tool and i do get the correct areas using that, its just when I calc a new field that I get wrong values.</p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=646762015-10-17T10:46:30ZNyall Dawson
<ul></ul><p>Is this using a virtual field? Could it be a duplicate of <a class="issue tracker-1 status-5 priority-4 priority- closed" href="https://issues.qgis.org/issues/12622" title="In virtual fields $area function computes always values using "None/planimetric" ellipsoid (Closed)">#12622</a>?</p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=646782015-10-17T13:23:02ZStefan Blumentrath
<ul></ul><p>Hi Andrew, QGIS computes - different from almost all other GIS - by default an ellipsoidal area measurement, and not one a kartesian one (at least as long as you do not set the measurement ellipsoid manually to "None/Planimetric" or turn off OTF-projection). That means e.g. if you digitize a square with 1000 x 1000 m boundary length, the returned area for it will not be 1 km2 but a slightly different number (e.g. 0.99986789 km2), depending on where you square is located relatively to the central median. You can find a quite long discussion about it here: <a class="issue tracker-1 status-5 priority-10 priority- closed" href="https://issues.qgis.org/issues/12057" title="Computed area is wrong when reprojection is active (Closed)">#12057</a><br />So, unless your results are not completely off, the difference you (and also Nyall - even if it is just 0.001ha in this case) are reporting may be intended behavior...</p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=646832015-10-17T15:35:51ZAndrew McAninch
<ul></ul><p>Nyall - It happens when I am adding a new field, not a virtual one, well, I haven't tested it with a virtual field, so it may behave differently with a virtual field. I can test that as well.</p>
<p>Stefan - Thanks, I am aware of this, but the errors I get are the same as I mentioned in the original bug report, which is to say they are off by at least an order of magnitude.</p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=646842015-10-17T15:54:32ZAndrew McAninch
<ul></ul><p>I tested this with a virtual field noticed something unexpected. I am looking at a feature where the correct area should be 3,988,722. With OTF on, when I calculate a new virtual field the output preview in the field calculator window is the same incorrect value I get when adding a new field, 369,889. However, the value that actually gets filled in the virtual field is 3988722, the correct value.</p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=646852015-10-17T16:32:53ZRandal Halerjhale@northrivergeographic.com
<ul><li><strong>File</strong> <a href="/attachments/download/9205/knox.zip">knox.zip</a> added</li></ul><p>I'm reading through All of this and I have a practical example:</p>
<p>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.</p>
<p>It seems like it's returning almost sq meters although the projection is in US Feet. Which <strong>almost</strong> maybe the ellipsoidal issue mentioned.</p>
<p>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.</p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=646862015-10-17T22:03:45ZMathieu Pellerin - nIRVnirvn.asia@gmail.com
<ul></ul><p>Playing around with Randal's shapefile, here are a couple of observations:<br />- the area shown (via identify tool) when OTF is off is 20.442 ha, and when OTF is on it is 20.538 ha which amounts to a 0.096 ha difference (0.5% more or less) and I have no idea if that is an acceptable variance or not<br />- when OTF is off, the field calculator returns the proper value for $area, that is 2200346.6519 feet<br />- when OTF is on, the field calculator is definitively broken (whether you create a new field, or update an existing field is irrelevant), and the $area value returned through it is 205380.4847 <br />- interestingly, if you label the polygon using the "$area" expression, that value is correct irrespective of whether OTF is on or off</p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=646882015-10-18T02:00:23ZNyall Dawson
<ul><li><strong>Assignee</strong> deleted (<del><i>Nyall Dawson</i></del>)</li></ul><p>Hmmm... I can't work out what the expected behaviour is here, and have run out of time for 2.12 fixes.</p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=646912015-10-18T03:52:35ZRandal Halerjhale@northrivergeographic.com
<ul></ul><p>This is one of those things that keeps getting lumped into the Ellipsoid issue. Heh. Which is quite maddening once you see the long winded discussion and then this Field Calculator thing just disappears into the fog. No worries - I know 2.12 was getting close so maybe this will make it during 2.13 for 2.14. As long as someone at the top knows it's happening I feel better.</p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=647022015-10-18T17:00:46ZMathieu Pellerin - nIRVnirvn.asia@gmail.com
<ul></ul><p>Randal,</p>
<p>What I see here is that when OTF is on, the $area value is returned in square meters (i.e. 205380.4847 = 20.538ha) which is a near-perfect match to the square foot value return when OTF is off (that is 2200346.6519 = 20.442ha).</p>
<p>Can you confirm this is the case with you too? If not, can you write down a precise step to reproduce any value that doesn't match the above?</p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=647032015-10-18T17:23:12ZRandal Halerjhale@northrivergeographic.com
<ul></ul><p>So when I go in (and check my math please - I've been working all day)</p>
<p>I've turned File -> Project Properties -> General -> Measure Tool -> Ellipsoid to Non/Planimetric (just to cover myself)</p>
<p>A. If I calculate the area with OTF off I get 2200346.65259 with EPSG:2240<br />B. OTF On I get 205380.48474 with EPSG:2240</p>
<p>If my math is correct to convert Sq Feet to Sq Meters I would multiply the value in A * 0.092903 (I blame google if this is wrong - ha) and I get 204418.805065569 (which is close)</p>
<p>If I project my shapefile to EPSG:26916 I get 204340.82666 with OTF off and 205381.07575 with OTF on.....</p>
<p>So I would say yes - you are correct it's square meters. Apparently whatever is happening isn't happening when I'm using a projection in meters (or it's happening very very little).</p>
<p>If that makes sense.</p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=652362015-11-07T10:26:02ZGiovanni Manghigiovanni.manghi@gmail.com
<ul><li><strong>Target version</strong> deleted (<del><i>Version 2.12</i></del>)</li></ul> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=654042015-11-10T02:24:41ZGiovanni Manghigiovanni.manghi@gmail.com
<ul><li><strong>Category</strong> set to <i>Field calculator</i></li></ul><p>It seems to me that in QGIS master things are ok. There is just still an issue with virtual fields</p>
<p><a class="issue tracker-1 status-5 priority-4 priority- closed" href="https://issues.qgis.org/issues/12622" title="In virtual fields $area function computes always values using "None/planimetric" ellipsoid (Closed)">#12622</a></p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=655332015-11-12T12:25:29ZAndrew McAninch
<ul><li><strong>File</strong> <a href="/attachments/download/9313/area_test.zip">area_test.zip</a> added</li></ul><p>Giovanni,<br />I am still getting the same behaviour when calculating a non-virtual field with 2.13-16.</p>
<p>Mathieu,<br />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:</p>
<p>correct area(m2) calculated area(m2) <br /> 9,213 12,829,041<br /> 13,437 3,686,013<br />140,552 16,559,293 <br />855,174 559,466</p>
<p>The steps I took were:<br />field calculator button<br />new field, integer = $area</p>
<p>Im attaching the shapefile I am using to test this with several test fields calculated so you can see the values I am getting.</p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=655772015-11-13T09:23:09ZGiovanni Manghigiovanni.manghi@gmail.com
<ul><li><strong>Priority</strong> changed from <i>Normal</i> to <i>Severe/Regression</i></li><li><strong>File</strong> <a href="/attachments/download/9315/area_test_3857.cpg.zip">area_test_3857.cpg.zip</a> added</li><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Open</i></li></ul><p>Andrew McAninch wrote:</p>
<blockquote>
<p>Giovanni,<br />I am still getting the same behaviour when calculating a non-virtual field with 2.13-16.</p>
</blockquote>
<p>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.</p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=659082015-11-27T10:55:48ZSteven Mizunospookster@netzero.net
<ul><li><strong>File</strong> <a href="/attachments/download/9359/QGIS-_13209-testing-results.xlsx">QGIS-_13209-testing-results.xlsx</a> added</li><li><strong>File</strong> <a href="/attachments/download/9358/10000sqft-test.zip">10000sqft-test.zip</a> added</li></ul><p>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.</p>
<p>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.</p>
<p>And I got curious about what happens if the geometries are changed -- moving or altering the shape.</p>
<p>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.<br />I considered that transforming to EPSG:3857, as some have done, throws in complications for finding the root cause of the problems.</p>
<p>The 10000sqft-test-2285 file was created to have a very specific known area for some tests.</p>
<p>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.</p>
<p>Not mentioned before, but there is another function that calculates area: <a class="wiki-page new" href="https://issues.qgis.org/projects/qgis/wiki/Area()">area()</a> -- more specifically, <a class="wiki-page new" href="https://issues.qgis.org/projects/qgis/wiki/Area($geometry)">area($geometry)</a> would appear to be equal to <a class="wiki-page new" href="https://issues.qgis.org/projects/qgis/wiki/$area">$area</a> (which it isn't.)<br />I'm not sure whether area() is strictly plane or can handle ellipsoidal calculations.</p>
<p>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.</p>
<p>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.</p>
<p>Based on testing I conducted:</p>
<p>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.</p>
<p>B. two different area calculations are used: one for <a class="wiki-page new" href="https://issues.qgis.org/projects/qgis/wiki/$area">$area</a>; a different one for <a class="wiki-page new" href="https://issues.qgis.org/projects/qgis/wiki/Area($geometry)">area($geometry)</a> -- 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.</p>
<p>This leads to confusion because of the very slightly different results.</p>
<p>C. from running some PostGIS queries, I believe that all of the QGIS area computations on area_test using <a class="wiki-page new" href="https://issues.qgis.org/projects/qgis/wiki/$area">$area</a> 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.</p>
<p>D. the Field calculator has confusing behavior on actual field vs. virtual field<br />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<br />2. Field Calculator: the $area value placed in an actual field is the area based on ellipsoid in meters</p>
<p>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.</p>
<p>----<br />data showing the above points:<br />[using QGIS dev 5b59609]</p>
A.
<ul>
<li>area_test feature ID=301/sqft_arc=144636: $area = 144636.18460 sq ft (OTF off) and 5626033.17938 (OTF on)</li>
</ul>
These two were very interesting and shouldn't happen (using feature ID= 301 and 303):
<ul>
<li>changing the shape of specific objects -- does not appreciably change the area calculated IF the area was way off. </li>
<li>moving specific objects -- changes the area calculated IF the area calc was way off</li>
</ul>
<ul>
<li>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) <br />I tested both area_test and area_test transformed to EPSG:32148 Washington N in meters, with similar results for both<br /><pre>
------------
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
------------
</pre></li>
</ul>
<p>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)</p>
<p>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.<br /><pre>
------------
-- 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;
------------
</pre><br />The pct_chg is not more than approx. +/- 0.025% (about 2.5 parts in 10000)</p>
<p>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.</p>
<p>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.</p>
<p>Projections like UTM cover large areas so they tend to be less accurate.</p>
<p>D. 1. & D. 2. see Excel worksheet: QGIS-#13209-testing-results.xlsx<br />this shows changing three variables and noting the results for the 10000sqft test files</p>
<p>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.</p>
<hr />
<p>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.</p>
<p>I am including an Excel worksheet showing the results for point D. as it is rather tedious to construct.</p>
<p>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 <br /> 10000sqft-test.zip containing: 10000sqft-test-2285.shp and 10000sqft-test-32148.shp</p>
I believe the tests I have put forth show that the following things need to be fixed:
<ul>
<li>the ellipsoidal area calculation used by <a class="wiki-page new" href="https://issues.qgis.org/projects/qgis/wiki/$area">$area</a> and Identify (most important!)</li>
<li>for plane area calculation <a class="wiki-page new" href="https://issues.qgis.org/projects/qgis/wiki/$area">$area</a> should be equal to <a class="wiki-page new" href="https://issues.qgis.org/projects/qgis/wiki/Area($geometry)">area($geometry)</a></li>
<li>the logic of Field Calculator as to how <a class="wiki-page new" href="https://issues.qgis.org/projects/qgis/wiki/$area">$area</a> is calculated and shown as well as stored in a field (actual vs. virtual) should be consistent</li>
</ul> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=669492016-01-06T04:07:03ZGiovanni Manghigiovanni.manghi@gmail.com
<ul></ul><p>see also <a class="issue tracker-1 status-5 priority-4 priority- closed" href="https://issues.qgis.org/issues/14057" title="$area bogus value (Closed)">#14057</a></p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=680492016-02-09T17:47:39ZNyall Dawson
<ul><li><strong>Assignee</strong> set to <i>Nyall Dawson</i></li><li><strong>Status</strong> changed from <i>Open</i> to <i>In Progress</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>50</i></li></ul> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=681892016-02-14T22:02:14ZNyall Dawson
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Feedback</i></li><li><strong>% Done</strong> changed from <i>50</i> to <i>100</i></li></ul><p>With 479d90a5ceec1c1b658aa101702ecf855e534987 this should now be resolved, with the one exception of virtual fields (<a class="issue tracker-1 status-5 priority-4 priority- closed" href="https://issues.qgis.org/issues/12622" title="In virtual fields $area function computes always values using "None/planimetric" ellipsoid (Closed)">#12622</a>).</p>
<p>I'd appreciate extensive testing and feedback so that we can get this closed before 2.14 is released.</p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=682652016-02-16T07:18:02ZAndrew McAninch
<ul></ul><p>Excellent! I briefly tested this in master with the data I had been using and the areas are calculating correctly. I will try to do some more thorough testing of measurements this week.</p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=684512016-02-21T14:12:43ZRandal Halerjhale@northrivergeographic.com
<ul></ul><p>So I just loaded master on ubuntu (pulling from deb <a class="external" href="http://qgis.org/debian-nightly">http://qgis.org/debian-nightly</a> wily main) and it still appears to not be working correctly with OTF checked. I checked a polygon that was 834 acres and did a $area/43560 and it appears to still be defaulting to meters. My projection is EPSG:2274. I'm still checking it but I wanted to leave a comment.</p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=684522016-02-21T14:22:21ZNyall Dawson
<ul></ul><p>Randal - did you check the new setting under project properties for area units? What's that set to?</p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=684532016-02-21T14:31:08ZRandal Halerjhale@northrivergeographic.com
<ul></ul><p>Holy Crap - It was set to square meters. I just switched it to square feet and it's working. You are my hero. I didn't know that was an option.</p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=684542016-02-21T14:42:27ZNyall Dawson
<ul></ul><p>It's a new option, introduced to help fix this issue. You may also want to check the "default units" under qgis options - > map tools. That's where you set the default values for the units for new projects.</p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=684552016-02-21T14:45:27ZRandal Halerjhale@northrivergeographic.com
<ul></ul><p>I'm so happy I could jump up and down.</p> QGIS Application - Bug report #13209: area not calculated correctly with OTF onhttps://issues.qgis.org/issues/13209?journal_id=685732016-02-25T19:12:32ZNyall Dawson
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Closed</i></li><li><strong>Resolution</strong> set to <i>fixed/implemented</i></li></ul>