QGIS » QGIS Application

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

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/

see also #3296

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...

see also #10966 ("with OTFR on $area is always computed in square meters even if the CRS is in feet").

see also #8558

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.

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.

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.

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...

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.

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.

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...

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...

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?

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.

BTW, SAGA gives for your Parma-polygon also 3 447,087 km2. I can compare other tools too if that is of relevance...

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.

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?

So, the question is: How is OTF supposed to affect measurements?

I'll be back on this a little later. Cheers.

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).

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.

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?

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?