Polygon area calculation error when the fly reprojection is activated

[qgib]

Author Name: Jean-Pierre LEFEVRE (Jean-Pierre LEFEVRE)
Original Redmine Issue: 14675
Affected QGIS version: master
Redmine category:vectors
Assignee: Nyall Dawson

---

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 (Jean-Pierre LEFEVRE)

[qgib]

Author Name: Jukka Rahkonen (Jukka Rahkonen)

---

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.

[qgib]

Author Name: Jean-Pierre LEFEVRE (Jean-Pierre LEFEVRE)

---

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.

[qgib]

Author Name: Jukka Rahkonen (Jukka Rahkonen)

---

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

[qgib]

Author Name: Jean-Pierre LEFEVRE (Jean-Pierre LEFEVRE)

---

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

[qgib]

Author Name: Jukka Rahkonen (Jukka Rahkonen)

---

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

[qgib]

Author Name: Harrissou Santanna (@DelazJ)

---

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.

---

• operating_system was changed from Ubuntu to
• os_version was changed from 14.04 64bits to
• fixed_version_id was configured as Future Release - High Priority
• priority_id was changed from Normal to Severe/Regression
• assigned_to_id was configured as Nyall Dawson

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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.

---

• fixed_version_id was changed from Future Release - High Priority to Version 2.16
• version was changed from 2.14.1 to master

[qgib]

Author Name: Jean-Pierre LEFEVRE (Jean-Pierre LEFEVRE)

---

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?

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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

that seems to be the real issue.

[qgib]

Author Name: Piers van der Torren (@pierstitus)

---

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 #20259 ?

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

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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.

---

• category_id was configured as Vectors

[qgib]

Author Name: Nyall Dawson (@nyalldawson)

---

Fixed in changeset "bf4cf51e1a259252d5a762845f20aaac12d672bf".

---

• status_id was changed from Open to Closed