Computed area is wrong when reprojection is active #20259
Comments
|
Author Name: Giovanni Manghi (@gioman) 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?
|
|
Author Name: Harrissou Santanna (@DelazJ) Yes, QGis 2.6 gives right value for the same layer/feature.
|
|
Author Name: Donovan Cameron (@saultdon) 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.
|
|
Author Name: Giovanni Manghi (@gioman) This was certainly working in previous qgis releases, like 2.0.1
|
|
Author Name: stefano nardone (@stefanon) 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 |
|
Author Name: Giovanni Manghi (@gioman)
|
|
Author Name: Maxim Broos (Maxim Broos) 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/ |
|
Author Name: Gerhard Spieles (Gerhard Spieles) see also #13356 |
|
Author Name: Stefan Blumentrath (@ninsbl) 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... |
|
Author Name: Giovanni Manghi (@gioman)
|
|
Author Name: Jürgen Fischer (@jef-n)
|
|
Author Name: Stefan Blumentrath (@ninsbl) also Probably also related: And some older likely related issues: Maybe worth writning a test for this bug, given it`s history. |
|
Author Name: Martin Dobias (@wonder-sk) The problem is most likely the same as #20579 - please try again with the latest master.
|
|
Author Name: Giovanni Manghi (@gioman) fixed in master.
|
|
Author Name: Stefan Blumentrath (@ninsbl) 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 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 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. |
|
Author Name: Stefan Blumentrath (@ninsbl) The problem is still present in QGIS code revision 2ff6f72 (Installed through OSGeo4W, 32bit, Win 7). |
|
Author Name: Giovanni Manghi (@gioman) Stefan Blumentrath wrote:
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. |
|
Author Name: Stefan Blumentrath (@ninsbl) 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. |
|
Author Name: Giovanni Manghi (@gioman) Stefan Blumentrath wrote:
the ellipsoid is set to the one of the project CRS, seems a reasonable choice to me.
I cannot see this difference. Can you attach sample data?
|
|
Author Name: Stefan Blumentrath (@ninsbl) 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: In all cases CRS of the source layer is EPSG 25832. 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.
|
|
Author Name: Giovanni Manghi (@gioman) Stefan Blumentrath wrote:
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
|
|
Author Name: Stefan Blumentrath (@ninsbl) 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... |
|
Author Name: Giovanni Manghi (@gioman) Stefan Blumentrath wrote:
because the area computed on a plane and computed on a curved surface are different, the latter being bigger of course.
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... |
|
Author Name: Stefan Blumentrath (@ninsbl) 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)). 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. 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? |
|
Author Name: Giovanni Manghi (@gioman) Stefan Blumentrath wrote:
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. |
|
Author Name: Stefan Blumentrath (@ninsbl) BTW, SAGA gives for your Parma-polygon also 3 447,087 km2. I can compare other tools too if that is of relevance... |
|
Author Name: Giovanni Manghi (@gioman) Stefan Blumentrath wrote:
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. |
|
Author Name: Giovanni Manghi (@gioman)
this thread is about the situatoin before the proposed (and committed) fix, so it isn't really pertinent, not anymore at least.
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.
Why choosing to have by default a less precise measurement when you can have a more precise one? |
|
Author Name: Giovanni Manghi (@gioman)
I'll be back on this a little later. Cheers. |
|
Author Name: Stefan Blumentrath (@ninsbl) GRASS 6.4.4 gives also 3 447,087 km2 for the Parma-Polygon. 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 #13356 (comment) BTW, Bug #13356 can probably be closed, since measurements are identical between Identify tool and Field calculator (see note 20 in this ticket). |
|
Author Name: Giovanni Manghi (@gioman) Stefan Blumentrath wrote:
good. Also Arcgis gives the same value with OTF off. Intersting enough ArcGIS disables the area measure tool when OTF is 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. |
|
Author Name: Stefan Blumentrath (@ninsbl) Giovanni Manghi wrote:
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 #19178)... After that a new ticket might be filed depending on user feedback? What do you think? |
|
Author Name: Randal Hale (@rjhale1971) 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? |
|
Author Name: Stefan Blumentrath (@ninsbl) Taking the liberty to reopen this ticket as the issue pops up again (see also: #21270). It was prioritized as blocker here, while it is not in the newer ticket.
|
|
Author Name: Nyall Dawson (@nyalldawson) Please test with current master, this may have been fixed with #21643
|
|
Author Name: Nyall Dawson (@nyalldawson) Reclosing - there's nothing new here, discussion can continue in #21270. Note that the fix for #21643 introduced some extra unit tests for this issue.
|
qgib
added
Bug
Author Name: Harrissou Santanna (@DelazJ)
Original Redmine Issue: 12057
Affected QGIS version: master
Redmine category:vectors
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 #19314).
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 issue(s): #13356 (relates), #19314 (relates), #20579 (relates), #20739 (relates), #20748 (duplicates), #21270 (relates)
Redmine related issue(s): 3296, 10966, 12406, 12622, 12633, 13209
The text was updated successfully, but these errors were encountered: