Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Zonal Statistics do not always consider correct area fraction #52223

Open
2 tasks done
coefficient1900 opened this issue Mar 14, 2023 · 0 comments
Open
2 tasks done

Zonal Statistics do not always consider correct area fraction #52223

coefficient1900 opened this issue Mar 14, 2023 · 0 comments
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Processing Relating to QGIS Processing framework or individual Processing algorithms

Comments

@coefficient1900
Copy link

coefficient1900 commented Mar 14, 2023

What is the bug or the crash?

When using the "Zonal statistics" algorithm it is not secured, that the complete area of the underlying raster layer, covered by the input vector layer, is incorporated in the calculation.

If there are polygons which do not cover more than one centroid of raster cells, the calculation will be processed as expected, regarding the pure fractions of the raster layer. (This behaviour ist considered as correct. Polygon 1, 2 and 5 in the test data and picture.)

But for polygons, covering more than one raster cell centroid, these complete cells are taken into consideration, even if they are not completely covered by the polygon (Polygon 3 and 4).

This mixture of handling raster cells in one algorithm is not only confusing. It also leads to wrong results.
The same issue was already mentioned here: #38273

(test data with included project here: data.zip)

Steps to reproduce the issue

  1. You have a raster layer and a covering polygon layer (in my example class_clipped and vector)
  2. Simply execute "Zonal statistics" and check the attribute table of the result.

calculation

  1. It is obvious that the result metrics of polygon 3 and 4 is not what you would expect due to the behaviour described above.

(You can do a validation with an intersect and simple arithmetic operations. The result of this is also included in the test data and shown in the picture as the "aggregated" layer.)

Versions

<style type="text/css"> p, li { white-space: pre-wrap; } </style>
QGIS version 3.28.3-Firenze QGIS code revision c12bcb2
Qt version 5.15.3
Python version 3.9.5
GDAL/OGR version 3.6.2
PROJ version 9.1.1
EPSG Registry database version v10.076 (2022-08-31)
GEOS version 3.11.1-CAPI-1.17.1
SQLite version 3.39.4
PDAL version 2.4.3
PostgreSQL client version unknown
SpatiaLite version 5.0.1
QWT version 6.1.6
QScintilla2 version 2.13.1
OS version Windows 10 Version 2009
       
Active Python plugins
qfieldsync v4.2.0
db_manager 0.1.20
grassprovider 2.12.99
MetaSearch 0.3.6
processing 2.12.99
sagaprovider 2.12.99
QGIS version 3.28.3-Firenze QGIS code revision [c12bcb2](https://github.com/qgis/QGIS/commit/c12bcb2f76c) Qt version 5.15.3 Python version 3.9.5 GDAL/OGR version 3.6.2 PROJ version 9.1.1 EPSG Registry database version v10.076 (2022-08-31) GEOS version 3.11.1-CAPI-1.17.1 SQLite version 3.39.4 PDAL version 2.4.3 PostgreSQL client version unknown SpatiaLite version 5.0.1 QWT version 6.1.6 QScintilla2 version 2.13.1 OS version Windows 10 Version 2009

Active Python plugins
qfieldsync
v4.2.0
db_manager
0.1.20
grassprovider
2.12.99
MetaSearch
0.3.6
processing
2.12.99
sagaprovider
2.12.99

Supported QGIS version

  • I'm running a supported QGIS version according to the roadmap.

New profile

  • I tried with a new QGIS profile

Additional context

Tests done with 3.22.16, 3.28.3, 3.28.4 on Windows, and also with 3.22.4 on an Ubuntu machine. Always the behaviour occourred which is described above.

@coefficient1900 coefficient1900 added the Bug Either a bug report, or a bug fix. Let's hope for the latter! label Mar 14, 2023
@agiudiceandrea agiudiceandrea added the Processing Relating to QGIS Processing framework or individual Processing algorithms label Mar 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Processing Relating to QGIS Processing framework or individual Processing algorithms
Projects
None yet
Development

No branches or pull requests

2 participants