Bug report #14675

Polygon area calculation error when the fly reprojection is activated

Added by Jean-Pierre LEFEVRE about 8 years ago. Updated almost 8 years ago.

Status:Closed
Priority:Severe/Regression
Assignee:Nyall Dawson
Category:Vectors
Affected QGIS version:master Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:
Crashes QGIS or corrupts data:No Copied to github as #:22639

Description

The area is wrong when the fly reprojection is enabled even if there are no other layers in the project.
you can check it with the attached file.

The behavior is the same with ubuntu 14.04 64bits (debian repository) and win7 32bits

Update with more info

The CRS from the project is EPSG:2154 and is the same as the CRS from the only one layer (dataset.shp).
I understand that there are small differences with differents projections, but i haven't changed the CRS. You can see also that the attributes from the object id=3 seems absurd (357.17 ha with OTF conversion instead of 113.59 ha without OTF).
The OTF conversion should not change anything since the CRS has remained the same. My data in natively in EPSG:2154 and QGIS converts it on-the-fly to EPSG:2154.

DatasetSHP.zip - Dataset (8.57 KB) Jean-Pierre LEFEVRE, 2016-04-13 04:41 AM

Associated revisions

Revision bf4cf51e
Added by Nyall Dawson almost 8 years ago

Fix incorrect area calculation for polygon (fix #14675)

Revision 5305486e
Added by Nyall Dawson almost 8 years ago

Fix incorrect area calculation for polygon (fix #14675)

(cherry-picked from bf4cf51e1a259252d5a762845f20aaac12d672bf)

History

#1 Updated by Jukka Rahkonen about 8 years ago

Please define how it is wrong. Does the OTF area differ from the area that you get if you re-project the file physically into the projection you use with OTF?

The area does not remain the same when you reproject data from one coordinate system into another. Comparison with your data follows.

Area in native projection "RGF93_Lambert_93"

ogrinfo -dialect sqlite -sql "select st_area(geometry) from datasetSHP limit 1" datasetSHP.shp
st_area(geometry) (Real) = 54197.9723561543

Area in UTM 32 (EPSG:32630)

ogrinfo -dialect sqlite -sql "select st_area(st_transform(geometry,32630)) from datasetSHP limit 1" datasetSHP.shp
st_area(st_transform(geometry,32630)) (Real) = 54769.161815754

Both areas are correct even they are different.

What area would you like to get if your data in natively in SRS "A" and QGIS converts it on-the-fly to SRS "B", area in "A" of area in "B"? What if you have another layer in the same QGIS project which is natively in "C" and it is reprojected into "B" as well, area in "C" or in "B"?

I would recommend not to measure areas with OTF at all but if it feels necessary then the results make most sense when they are measured in the on-the-fly SRS.

#2 Updated by Jean-Pierre LEFEVRE about 8 years ago

The CRS from the project is EPSG:2154 and is the same as the CRS from the only one layer (dataset.shp).
I understand that there are small differences with differents projections, but i haven't changed the CRS. You can see also that the attributes from the object id=3 seems absurd (357.17 ha with OTF conversion instead of 113.59 ha without OTF).
The OTF conversion should not change anything since the CRS has remained the same. My data in natively in EPSG:2154 and QGIS converts it on-the-fly to EPSG:2154.

#3 Updated by Jukka Rahkonen about 8 years ago

Thanks, makes sense now. Could you add this valuable information into the description?

#4 Updated by Jean-Pierre LEFEVRE about 8 years ago

Jukka Rahkonen wrote:

Thanks, makes sense now. Could you add this valuable information into the description?

I would like, but I don't know how.

Sorry

#5 Updated by Jukka Rahkonen about 8 years ago

Hmm, it seems really that even the author of the ticket does not have rights to edit it.

#6 Updated by Harrissou Santanna about 8 years ago

  • Operating System deleted (Ubuntu)
  • OS version deleted (14.04 64bits)
  • Target version set to Future Release - High Priority
  • Priority changed from Normal to Severe/Regression
  • Assignee set to Nyall Dawson

This is a very bad bug. Should have been fixed if I recall well, so i set it to blocker.
Nyall, I assign it to you just to ping you given that you worked hard on this side last release. Feel free to unassign yourself.
Thanks.

#7 Updated by Giovanni Manghi about 8 years ago

  • Target version changed from Future Release - High Priority to Version 2.16
  • Affected QGIS version changed from 2.14.1 to master

small differences between with/without OTF are expected, in the first case the computations are made over a ellipsoid/geoid and the CRS may (or may not) be conservative for areas. In the second case computations are made on a plane. Said that the are of that feature with OTF on is as a fact completely wrong.

#8 Updated by Jean-Pierre LEFEVRE about 8 years ago

The relative or absolute error varies enormously from one polygon to another. It is surprising.
Why error is so high only for the polygon id=3?
It depends on the complexity of the geometry?
It depends on the concavity or convexity?

#9 Updated by Giovanni Manghi about 8 years ago

Why error is so high only for the polygon id=3?

that seems to be the real issue.

#10 Updated by Piers van der Torren almost 8 years ago

I also encountered this problem, and even some very simple geometries give absurd areas. I'll try to make put some problematic cases in a test file if that's appreciated.
At least it is a very serious issue, how to trust a GIS that can't reliably calculate an area?

How is this bug related to #12057 ?

Besides being wrong the function naming is a bit inconsistent (and incomplete). The documentation luckily is there, but still it would make sense to make it more sensible.

Now there are two ways to calculate area in the Field Calculator:
- $area: takes into account OTF ellipsoid and project area unit settings
- area($geometry): always planimetric in the layer SRS

Wouldn't it make sense to let $area and area() use the same method, and add $area_planimetric and area_planimetric() to be their planimetric counterparts?

And the same of course for $length and $perimeter

#11 Updated by Giovanni Manghi almost 8 years ago

  • Category set to Vectors

Still true on the latest master.

Piers van der Torren wrote:

I also encountered this problem, and even some very simple geometries give absurd areas. I'll try to make put some problematic cases in a test file if that's appreciated.

it would be very good, thanks.

At least it is a very serious issue, how to trust a GIS that can't reliably calculate an area?

I agree.

Besides being wrong the function naming is a bit inconsistent (and incomplete). The documentation luckily is there, but still it would make sense to make it more sensible.

Now there are two ways to calculate area in the Field Calculator:
- $area: takes into account OTF ellipsoid and project area unit settings
- area($geometry): always planimetric in the layer SRS

Wouldn't it make sense to let $area and area() use the same method, and add $area_planimetric and area_planimetric() to be their planimetric counterparts?

And the same of course for $length and $perimeter

please raise this question also in the developers mailing list.

#12 Updated by Nyall Dawson almost 8 years ago

  • Status changed from Open to Closed

Also available in: Atom PDF