Bug report #12057
Computed area is wrong when reprojection is active
Status: | Closed | ||
---|---|---|---|
Priority: | Severe/Regression | ||
Assignee: | - | ||
Category: | Vectors | ||
Affected QGIS version: | master | Regression?: | No |
Operating System: | Easy fix?: | No | |
Pull Request or Patch supplied: | No | Resolution: | fixed/implemented |
Crashes QGIS or corrupts data: | No | Copied to github as #: | 20259 |
Description
New description:
with OTFR on the area returned by the field calculator or the identify tool is completely wrong.
Moreover the area is always computed in square meters even if CRS is in feet (see #10966).
Tested on QGIS 2.8 and master
Select Identify tool
click on a feature
read the results in the Identify panels
the value shown for the area is 0,000 square meter. see attached file.
QGIS master 7b1f9ee
Osgeo4W 64 bits
Related issues
History
#1 Updated by Giovanni Manghi almost 10 years ago
- Priority changed from Severe/Regression to Normal
- Category set to Vectors
- Status changed from Open to Feedback
- Target version deleted (
Version 2.8)
Cannot confirm here, please attach a sample data.
Does it returns the right result, with the very same data and project, using an older qgis version than master?
#2 Updated by Harrissou Santanna almost 10 years ago
- Status changed from Feedback to Closed
Yes, QGis 2.6 gives right value for the same layer/feature.
But this issue can be closed, as next version of master has solved it.
#3 Updated by Donovan Cameron almost 10 years ago
- File wildlife_management_areas.zip added
- Status changed from Closed to Reopened
Sorry, I don't have a master version to test against and using 2.8.0 on linux, but when OTF is turned on, the derived area from the identify tool always says 0.000 m2.
I've attached a sample dataset for testing.
#4 Updated by Giovanni Manghi almost 10 years ago
- Target version set to Version 2.8.1
- Priority changed from Normal to Severe/Regression
This was certainly working in previous qgis releases, like 2.0.1
#5 Updated by stefano nardone over 9 years ago
Does the same here too: derived identify information area is shown as zero square meters with On The Fly CRS transformation active, works correctly if I have OTF disabled. QGIS 2.8.1 + Linux Ubuntu 14.04.2 LTS
#6 Updated by Giovanni Manghi over 9 years ago
- Subject changed from Identify Tool gives wrong derived area to Computed area is wrong when reprojection is active
#7 Updated by Maxim Broos over 9 years ago
For sake of completeness:
This is a gis.stackexchange discussion on the same topic: http://gis.stackexchange.com/questions/143080/qgis-area-calculation-differs-when-on-the-fly-crs-transformation-enabled/
#8 Updated by Gerhard Spieles over 9 years ago
see also #3296
#9 Updated by Stefan Blumentrath over 9 years ago
I can confirm this issue on Windows 7, QGIS 2.8.1 and 2.6.1 (both 32bit). In addition I had a very similar issue with distance measuring. After changing CRS forth and back (due to adding and removing an OpenLayers map) the length measurement tool reported the width of a regular grid I created to be 500m, yet I know it was 250m. After deactivating OTF-projection and restarting QGIS everything was OK again...
#10 Updated by Giovanni Manghi over 9 years ago
- Target version changed from Version 2.8.1 to Version 2.8.2
#11 Updated by Jürgen Fischer over 9 years ago
- Target version changed from Version 2.8.2 to Future Release - High Priority
#12 Updated by Giovanni Manghi over 9 years ago
see also #10966 ("with OTFR on $area is always computed in square meters even if the CRS is in feet").
#13 Updated by Giovanni Manghi over 9 years ago
see also #8558
#14 Updated by Stefan Blumentrath over 9 years ago
also
related to QGIS Application - Bug report #9060 Area is wrong in QGIS master (again), closed, 11/13/2013
related to QGIS Application - Bug report #10799 Measure ellipsoid should be set when the project CRS is not a PCS, open, 07/03/2014
related to QGIS Application - Bug report #10392 Ellipsoid for measurement keeps getting reset, closed, 05/29/2014
related to QGIS Application - Feature request #4252 different built-in tools calculate inconsistent polygon areas, open, 09/01/2011
#3296
Probably also related:
Bug report #12406 QgsDistanceArea.measure(geometry) - for Polygons in WGS84, open
Bug report #12634 Proj4 Exception in Measure tool leaves qgis in wait state (OTF On), closed
Bug report #12143 Wrong measurements when background is from a tiled service, open
Bug report #4628 Measure area - result varies with ellipsoidal toggling & with no. of vertices in polygon, closed
And some older likely related issues:
Bug report #301 derived area is calculated wrong, closed, version 0.9
Bug report #518 measure tool was not correct!, closed, version 0.9
Bug report #631 Measurement tool is not calibrated properly, closed, version 0.9
Bug report #1024 wrong unit at area measurement tool, closed, version ?
Feature request #1219 OTFT on, layer's and project's CRS the same: measure tools and Identify Features return impossible measurments, closed, version 0.9.1
Bug report #1333 QGIS measure tools, closed, version 1.0.2
Feature request #1433 measurements and scale broken in latlon, closed, version 1.2.0
Bug report #1687 Measure tool is very wrong, closed, version 1.0.1
Bug report #1969 Measure tools and scale give wrong readings with OTFR disabled, closed, version 2.0
Bug report #2160 "on the fly" reprojection distorts calculated polygon area, closed, version 1.4.0
Bug report #4416 Measure area wrong if ellipsoid off, closed, version ?
Bug report #4628 Measure area - result varies with ellipsoidal toggling & with no. of vertices in polygon, closed, version 1.7.2
Bug report #5332 Wrong Area for large polygons in vector/Geometry Tools/Export/Add Geometry Columns, closed, version 1.8.0
Feature request #5972 Measure Line, closed, version 1.8
Bug report #7558 Error with Measuring tool, closed, version ?
Bug report #11784 Measure Line behaviour when "On the fly" enabled, open, version 2.6.0
Bug report #11713 Measure tool ellipsoid defaults to 'None/Planametric' regardless of previous ellipsoid selection, closed, version 2.8
Bug report #11919 Calculation of areas in feet off by a factor of 10 in Illinois east projection, closed, version 2.6.1
Feature request #12098 "On the fly reprojection" warning, open, version ?
Maybe worth writning a test for this bug, given it`s history.
#15 Updated by Martin Dobias over 9 years ago
- Status changed from Reopened to Feedback
The problem is most likely the same as #12406 - please try again with the latest master.
#16 Updated by Giovanni Manghi over 9 years ago
- Status changed from Feedback to Closed
- Resolution set to fixed/implemented
fixed in master.
#17 Updated by Giovanni Manghi over 9 years ago
- Status changed from Closed to Reopened
- Resolution deleted (
fixed/implemented)
Martin Dobias wrote:
The problem is most likely the same as #12406 - please try again with the latest master.
sorry, it is not fixed.
#18 Updated by Stefan Blumentrath over 9 years ago
I can second that it is not fixed on OSGeo4W (QGIS e8587c3) on Win 7.
I created a regular grid in two different CRS (25832 and 25833) of 1kmx1km for testing.
With OTF on, the field calculator returns an area of 992xxx meter, with OTF off the result is correctly: 1000000m2
The same applies for perimeter, which has a little imprecision when OTF is on (4001.x m instead of 4000m).
The derived area in the "Identify results" is 0.0000 m2 when OTF is on, while it is correct and precise (100.0 ha) when OTF is off.
The derived perimeter is identical with values from field calculator (4001m).
The distance measure tool lacks precision too. It measures the width of the 1000m grid to be 1000.325 m when OTF is on, while it returns 1000.0 m when OTF is off. The same applies for the area measure tool (99.4 ha, when OTF is on, 100.0 ha when OTF is off).
All this applies for both grids and independent from Project CRS to be 25833 or 25832.
#19 Updated by Giovanni Manghi over 9 years ago
Stefan Blumentrath wrote:
I can second that it is not fixed on OSGeo4W (QGIS e8587c3) on Win 7.
this build does not yet includes the probable fix. I have also tested the same build... need to wait for the next nightly build or compile myself.
#20 Updated by Stefan Blumentrath over 9 years ago
The problem is still present in QGIS code revision 2ff6f72 (Installed through OSGeo4W, 32bit, Win 7).
However, "Identify results" does no longer return 0.0000 m2 for my 1km vector grid cells, but (wrongly) 99.4 ha when OTF is on. Results between "Identify", and "Measure tool" and "Field calculator" seem to be identical now...
#21 Updated by Giovanni Manghi over 9 years ago
Stefan Blumentrath wrote:
The problem is still present in QGIS code revision 2ff6f72 (Installed through OSGeo4W, 32bit, Win 7).
However, "Identify results" does no longer return 0.0000 m2 for my 1km vector grid cells, but (wrongly) 99.4 ha when OTF is on. Results between "Identify", and "Measure tool" and "Field calculator" seem to be identical now...
what ellipsoid are you using? is defined in project properties. If you set it to "none/planar" the the returned area is 1sqkm, otherwise is slightly different, but right and therefore this issue (and probably the many others related) is fixed.
#22 Updated by Stefan Blumentrath over 9 years ago
It is indeed as you describe. Measurements are accurate when I set the ellipsoid back to "none/planar". However, the ellipsoid - in my case "GRS 1980" (which is the ellipsoid of the CRS I use (EPSG:25832)) is set auto-magically by QGIS when OTF is activated. IMHO, QGIS should not define the ellipsoid, if that was not appropriate...
Please note, that measurements in QGIS (2ff6f72) also differ between OTF on / off, when project CRS and layer CRS are identical. Meaning a polygon of 1 km2 in 25832, is not 1 km2 (but 99.3 ha) when "reprojected" OTF to 25832 (defined as project CRS). Maye I lack some basic knowledge in geodetics here... Why should the area differ in this case differ only because OTF is on?
In comparison OTF in PostGIS gives no difference in area when a geometry is reprojected to it`s source CRS: For a vector grid in 25832 ST_Area(geom) = ST_Area(ST_Transform(geom, 25832)) --> True.
#23 Updated by Giovanni Manghi over 9 years ago
- Resolution set to fixed/implemented
- Status changed from Reopened to Closed
- Target version changed from Future Release - High Priority to Version 2.10
Stefan Blumentrath wrote:
It is indeed as you describe. Measurements are accurate when I set the ellipsoid back to "none/planar". However, the ellipsoid - in my case "GRS 1980" (which is the ellipsoid of the CRS I use (EPSG:25832)) is set auto-magically by QGIS when OTF is activated. IMHO, QGIS should not define the ellipsoid, if that was not appropriate...
the ellipsoid is set to the one of the project CRS, seems a reasonable choice to me.
Please note, that measurements in QGIS (2ff6f72) also differ between OTF on / off, when project CRS and layer CRS are identical. Meaning a polygon of 1 km2 in 25832, is not 1 km2 (but 99.3 ha) when "reprojected" OTF to 25832 (defined as project CRS). Maye I lack some basic knowledge in geodetics here... Why should the area differ in this case differ only because OTF is on?
I cannot see this difference. Can you attach sample data?
#24 Updated by Stefan Blumentrath over 9 years ago
- Status changed from Closed to Reopened
- File sqkm_grid_epsg_25832.sqlite added
- Target version changed from Version 2.10 to Future Release - High Priority
Please find attached an SQLite DB for testing. It contains one 1km2 grid cell in EPSG 25832. In the attribute table I compared area measures of PostGIS and QGIS when re-projecting OTF to:
EPSG 25832 (same as layer)
EPSG 25833 neighboring UTM zone, same ellipsoid
EPSG 3410 an arbitrary chosen, completely different CRS.
In all cases CRS of the source layer is EPSG 25832.
CRS;Area PostGIS;Area QGIS
No OTF;1000000;1000000
OTF to 25832;1000000;990073.641680859
OTF to 25833;996081.791878303;990073.641680859
OTF to 3410;991263.3653474;1000000
Strange enough, I got exactly the same results with different CRS / UTM zones, when OTF-reprojection to the same ellipsoid. I double-checked that with e.g. 25836, and this behavior is the same there too. Reprojecting to a completely different CRS resulted in an area of excactly 1km2, which seems a bit odd.
#25 Updated by Giovanni Manghi over 9 years ago
- File er_25832.zip added
- Status changed from Reopened to Closed
Stefan Blumentrath wrote:
Please find attached an SQLite DB for testing. It contains one 1km2 grid cell in EPSG 25832. In the attribute table I compared area measures of PostGIS and QGIS when re-projecting OTF to:
EPSG 25832 (same as layer)
EPSG 25833 neighboring UTM zone, same ellipsoid
EPSG 3410 an arbitrary chosen, completely different CRS.In all cases CRS of the source layer is EPSG 25832.
CRS;Area PostGIS;Area QGIS
No OTF;1000000;1000000
OTF to 25832;1000000;990073.641680859
OTF to 25833;996081.791878303;990073.641680859
OTF to 3410;991263.3653474;1000000Strange enough, I got exactly the same results with different CRS / UTM zones, when OTF-reprojection to the same ellipsoid. I double-checked that with e.g. 25836, and this behavior is the same there too. Reprojecting to a completely different CRS resulted in an area of excactly 1km2, which seems a bit odd.
There is something wrong with the data you used to make this test. In fact when I add the layer to QGIS it says that the CRS is not recognized and that it sets to WGS84. In your case you may have QGIS configured to automatically give the layers another CRS, maybe 25832, so you may have the feeling that your input is in 25832 but is not.
I attach here a shapefile that is originally in 25832, and made the same tests you made, the results are consistent to me.
Anyway if you really find something is still wrong with area computation then better open a new ticket. The main issue seems solved (the completely wrong values), if there is still something wrong this is because we need to fine tune how ellipsoid are set with OTR and eventually why there are differences compared to other packages.
-------
I tested measuring the second province from the left, Parma
3 449,766 km² OTF ON (25832)/GRS80
3 447,087 km² OTF OFF
3 447,087 km² OTR ON (25832)/planar
3 447,087 km² OTR ON (25833)/planar
3 447,087 km² OTR ON (3410)/planar
#26 Updated by Stefan Blumentrath over 9 years ago
With your data I get the same results as you. Yet, it seems that measurement results are in principle not different from what my test data ended up with. I am struggling with understanding why it should be considered OK that results differ between "OTF ON (25832)/GRS80" (which is the layer CRS) and "OTF OFF" by more than 2 km2? And should not area differ when measured using different CRSes?
Is a new ticket (yet another related) worth the extra work (this ticket is after all named "Computed area is wrong when reprojection is active"), and to me this still seems to be the case? I would consider 2km2 more than rounding imprecision...
BTW. when I choose a CRS for OTF which is based on the same ellipsoid as source layer, the ellipsoid for measuring is set to the one of the CRS of the layer. If the ellipsoid differs between data and project, the ellipsoid for measurement is automatically set to none/planar.
Just as a side note: Data were produced with QGIS (Vector -> Research tools -> Vector grid) while in a project with CRS defined as 25832 (OTF off) and they ended up where expected. So they should be in 25832, even if CRS is not saved in the SQLite DB I attached. When I had them in PostGIS they were treated as 25832 any way, and area measurements were accurate there...
#27 Updated by Giovanni Manghi over 9 years ago
Stefan Blumentrath wrote:
With your data I get the same results as you. Yet, it seems that measurement results are in principle not different from what my test data ended up with. I am struggling with understanding why it should be considered OK that results differ between "OTF ON (25832)/GRS80" (which is the layer CRS) and "OTF OFF" by more than 2 km2?
because the area computed on a plane and computed on a curved surface are different, the latter being bigger of course.
And should not area differ when measured using different CRSes?
if you don't use an ellipsoid then you computing on a plane... and on a plane a square meter is always a square meter...
#28 Updated by Stefan Blumentrath over 9 years ago
According to http://www.statistica.parma.it/, the area of the Province of Parma is 3.447,48 km2. That means either the Italian test data is quite imprecise or the measurement in QGIS is quite a bit off when OTF is on (and the default measurement ellipsoid is used). While results are closer to the official numbers when OTF is off or the measurement ellipsoid is manually set to None / Planimetric …
Now I also tested with data in geographic CRS (latlon/EPSG:4326), more precisely a 1 x 1 degree “square” (~ Polygon(0 0, 0 1, 1 1, 1 0, 0 0)).
Measurement with OTF on, with a geographic CRS defined for the project (EPSG: 4326, Measurement ellipsoid: default (WGS84)) leads to results in a reasonable dimension (12 512.965 km²).
Measurement with OTF on, with a geographic CRS defined for the project (EPSG: 4326, Measurement ellipsoid: manually set to None / Planimetric) leads to results in a reasonable dimension (12 429.846 km², but different from Measurement ellipsoid WGS84).
Measurement with OTF off, with a geographic CRS defined for the project (EPSG: 4326, Measurement ellipsoid: default (None / Planimetric)) leads to results in a reasonable dimension (12 429.846 km², but different from results when project CRS is 25832).
Measurement with OTF on, with a projected CRS defined for the project (EPSG: 25832, Measurement ellipsoid: default (GRS1980)) leads to results in a reasonable dimension (12 512.965 km²).
Measurement with OTF on, with a geographic CRS defined for the project (EPSG: 4326, Measurement ellipsoid: manually set to None / Planimetric) leads to results in a reasonable dimension (12 429.846 km²).
Measurement with OTF off, with a projected CRS defined for the project (EPSG: 25832, Measurement ellipsoid: default (None / Planimetric)) leads to unreasonable results because data is treated as XY (1 m2, perimeter of 4m).
If the area computed on a curved surface was supposed to be bigger than the area computed on a plane (as you wrote), then the measurements I made in QGIS with “OTF on” using the 1km2 vector grid earlier are not correct either because area was smaller when computed on ellipsoid.
Maybe you are willing to help me one last time to understand what is going on here.
OTF does not re-project the data/layer to the CRS defined for the project before measurement. Otherwise, results would (must) be different when different project CRS are used, right? And results should be identical - comparing OTF on / off - when layer CRS and project CRS are identical. Both is not the case.
Neither does it “only” apply the measurement ellipsoid defined in the project to the data/layer. In this case measurements would (must) be identical when the ellipsoid of the layer CRS and the measurement ellipsoid are identical, should`nt they? This is not the case either.
Furthermore, setting the ellipsoid for measurement to “None / Planimetric”, does not treat data as XY, otherwise my 1 degree vector grid should result in an area of 1 square unit, regardless project CRS.
And finally, switching OTF off does not mean that data is treated as XY either, at least this not the case when the project CRS is geographic. However, it seems to be the case when project CRS is projected.
So, the question is: How is OTF supposed to affect measurements?
Do you really consider this bug properly fixed so the ticket can be closed? It seems that I am not the only one who is uncomfortable with the current measurement behavior: http://osgeo-org.1560.x6.nabble.com/QGIS-2-8-2-no-values-calculating-area-with-Export-Add-Geometry-Columns-on-Ellipsoid-tt5208252.html#a5208298).
Again, this is the probably most used and most essential GIS functionality. In 2.8.2 it leads to obviously wrong data (Area = 0.0m when OTF is on). I would actually prefer that over the slightly wrong data, because users can see the error immediately…
Maybe a simple means of improving the situation is making the measurement ellipsoid "None / Planimetric" thje default also when OTF is on?
#29 Updated by Giovanni Manghi over 9 years ago
Stefan Blumentrath wrote:
According to http://www.statistica.parma.it/, the area of the Province of Parma is 3.447,48 km2. That means either the Italian test data is quite imprecise or the measurement in QGIS is quite a bit off when OTF is on (and the default measurement ellipsoid is used). While results are closer to the official numbers when OTF is off or the measurement ellipsoid is manually set to None / Planimetric …
we don't really know how/when and using what input data this value was computed, so it is not really useful in the analysis to try understand if qgis does the right thing.
I will try to answer the rest as soon as I can. Cheers.
#30 Updated by Stefan Blumentrath over 9 years ago
BTW, SAGA gives for your Parma-polygon also 3 447,087 km2. I can compare other tools too if that is of relevance...
#31 Updated by Giovanni Manghi over 9 years ago
Stefan Blumentrath wrote:
BTW, SAGA gives for your Parma-polygon also 3 447,087 km2. I can compare other tools too if that is of relevance...
this is a good news, isn't it? :)
of course comparing with as many other gis packages is good. If you can, it would be very appreciated.
#32 Updated by Giovanni Manghi over 9 years ago
Do you really consider this bug properly fixed so the ticket can be closed? It seems that I am not the only one who is uncomfortable with the current measurement behavior: http://osgeo-org.1560.x6.nabble.com/QGIS-2-8-2-no-values-calculating-area-with-Export-Add-Geometry-Columns-on-Ellipsoid-tt5208252.html#a5208298).
this thread is about the situatoin before the proposed (and committed) fix, so it isn't really pertinent, not anymore at least.
Again, this is the probably most used and most essential GIS functionality. In 2.8.2 it leads to obviously wrong data (Area = 0.0m when OTF is on). I would actually prefer that over the slightly wrong data, because users can see the error immediately.
I personally don't agree, but this doesn't count much. Anyway from the test I have made I was (and still am) pretty confident that things are ok now.
Maybe a simple means of improving the situation is making the measurement ellipsoid "None / Planimetric" thje default also when OTF is on?
Why choosing to have by default a less precise measurement when you can have a more precise one?
#33 Updated by Giovanni Manghi over 9 years ago
So, the question is: How is OTF supposed to affect measurements?
I'll be back on this a little later. Cheers.
#34 Updated by Stefan Blumentrath over 9 years ago
GRASS 6.4.4 gives also 3 447,087 km2 for the Parma-Polygon.
That is good news for those who turn off OTF or manually set the ellipsoid to None/Planimetric (because they will get this value too).
Those who use default settings in QGIS with OTF ON and Measurement ellipsoid GRS80, however, end up with 3 449,766 km² (se your Note 25 in this ticket). I guess they will wonder where the 2 km2 come from... Esp. since GRS80 is the ellipsoid both layer and project CRS is based on...
This issue has been discussed also in #3296-11
BTW, Bug #3296 can probably be closed, since measurements are identical between Identify tool and Field calculator (see note 20 in this ticket).
#35 Updated by Giovanni Manghi over 9 years ago
Stefan Blumentrath wrote:
GRASS 6.4.4 gives also 3 447,087 km2 for the Parma-Polygon.
That is good news for those who turn off OTF or manually set the ellipsoid to None/Planimetric (because they will get this value too).
good. Also Arcgis gives the same value with OTF off. Intersting enough ArcGIS disables the area measure tool when OTF is ON.
Those who use default settings in QGIS with OTF ON and Measurement ellipsoid GRS80, however, end up with 3 449,766 km² (se your Note 25 in this ticket). I guess they will wonder where the 2 km2 come from... Esp. since GRS80 is the ellipsoid both layer and project CRS is based on...
I don't think really there is nothing wrong. The same area measured on an ellipsoid it usually lead to a bigger value compared to the same measured on a plane. I wrote 'usually' because I was remembered that not all CRSs are conservative for areas, so it can also happen the area value (with OTF on) is lower than the one computed on a plane (OTF off).
Regarding one of the cases in comment 28
"Measurement with OTF off, with a projected CRS defined for the project (EPSG: 25832, Measurement ellipsoid: default (None / Planimetric)) leads to unreasonable results because data is treated as XY (1 m2, perimeter of 4m)."
this does not make sense at all (mixing a layer with a geographic CRS and nother with a projected one and OTF off): with OTF off you elect to use the units defined in the project properties. If you have meters then is normal that the layer with the geographic CRS will be measured in meters. But again, it is not a case that make much sense.
#36 Updated by Stefan Blumentrath over 9 years ago
Giovanni Manghi wrote:
this does not make sense at all (mixing a layer with a geographic CRS and nother with a projected one and OTF off)
The point here was mainly to systematically check the behavior with the all possible combinations of relevant variables. Nevertheless, this behavior is addressed in #10799.
Summing up, at least GRASS, SAGA, and ArcGIS (and likely also PostGIS) calculate 3 447,087 km2 for Parma (using cartesian maths / planimetric measure by default, resulting in numbers coherent with official statistics). Up to now, only QGIS is reported to measure 3 449,766 km2 for Parma (using an ellipsoidal / geodesic area measure as the default).
So, I think we can conclude that the area calculation may give the correct ellipsoidal area, but that ellipsoidal area is at least very unusual.
I do not have the knowledge to judge if ellipsoidal area calculation is generally more accurate compared to planimetric area calculation (assuming the chosen PCS is appropriate for the data and purpose) and I could not find a reference on that on the internet (a pointer would be appreciated). However, if I understood correctly, the code for area measurement in QGIS is copied from GRASS. With my amateur perspective I would assume the GRASS-devs have a good reason for sticking to planimetric calculations, given that they have the ellipsoidal measure in their code base (for quite some years now)... According to the documentation (http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//00s500000022000000) ArcGIS always calculates area planar (and geodesic measurements are only available for distances)...
Closing, - thanks to your explanations - it seems now OK for me too, to close this ticket. So, sorry for the noise.
Yet, I think it would be important that the Documentation is explicit about the fact that the default area (and distance) measurements in QGIS disregard both Project and Layer CRS (using only the ellipsoid from the Project CRS by default), esp. given that this behavior is different from all other tested GIS. The lack of documentation here is probably the reason why the measurements often are perceived as inaccurate or wrong?!
In addition, I could imagine posting a question on the UX-mailing list regarding the favored behavior of QGIS with OTF on/off (here also other, related usability issues could kick in: e.g. http://osgeo-org.1560.x6.nabble.com/Changing-project-crs-td4940240.html or #10799)... After that a new ticket might be filed depending on user feedback? What do you think?
#37 Updated by Randal Hale about 9 years ago
So I just tested this under 2.11 master.
As of right now if I perform an area calculation in 2.11 master with EPSG:2240 the area comes out to be 0 (actually a very very small number). If I turn OTF off - it's right (I'm doing $area/43560 to get acres). Do I need to explain to clients that OTF needs to be off for area calculations?
#38 Updated by Stefan Blumentrath about 9 years ago
- Status changed from Closed to Reopened
- Target version changed from Future Release - High Priority to Version 2.12
Taking the liberty to reopen this ticket as the issue pops up again (see also: #13209). It was prioritized as blocker here, while it is not in the newer ticket.
Maybe this is really an issue for a unit test, as Matthias Kuhn indicated, given the long history? Area measurement is a basic and central functionality of any GIS!
#39 Updated by Nyall Dawson about 9 years ago
- Status changed from Reopened to Feedback
Please test with current master, this may have been fixed with #13601
#40 Updated by Nyall Dawson about 9 years ago
- Status changed from Feedback to Closed