Bug report #14508

Single part to multipart yields multipart polygons with incorrect areas

Added by Mattias Lindman about 8 years ago. Updated almost 7 years ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Processing/QGIS
Affected QGIS version:2.12.3 Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:invalid
Crashes QGIS or corrupts data:No Copied to github as #:22481

Description

In a land cover study I want to derive the total area for each land cover type in a land cover layer (vector data). In order to do this I tried to use Vector/Geometry tools/Single part to Multipart in order to obtain an attribute table with one row per land cover type. By using the field calculator it should then be possible to derive the total area of each multipart land cover feature.

By comparing the obtained areas from the multipart layer with the sum of the single part areas for each land cover type in the original layer it turns out that there are quite significant differences, in the range 5-10 % for most land cover types. A visual comparison of the maultipart and the singlepart layer at a few locations does however not reveal any differences in the geometry that can explain the differences in the areal estimates.

In order to provide the possibility to reproduce the problem I attach an extract from the land cover layer containing individual shrubland polygons.

I have tested the singlepart to multipart conversion using both QGIS 2.8.7 and 2.12.3 and the problem is the same in both versions. I am running QGIS using Windows 8.

BugReportData_SingleToMultipart.zip (717 KB) Mattias Lindman, 2016-03-16 03:57 AM

History

#1 Updated by Maximilian Krambach about 8 years ago

I tested your data and can see that the "multipart" output is indeed about 5-10% bigger than the input. Not just in area calculation, but also in geometry. It seems that some rings are filled that should not be filled. The pattern seems a bit random. Some (~10%) rings are filled correctly, most (~70%) incorrectly, and some (~20%) partially correct.

As a workaround, I suggest (vector-Analysis-Basic statistics) which outputs the statistics of a field (e.g. area) of all features in the layer.

In terms of code it seems that quite a few rings ("interiorRing") become parts("exteriorRing") somewhere during the operation. Could this be a memory issue, as they are all stored in one list (300.000+ vertices)? Or maybe some confusion between the first item of a polygon (exteriorRing) and the following (InteriorRing)?

#2 Updated by Giovanni Manghi almost 8 years ago

  • Operating System deleted (Windows 8)

The layer has some errors, for example if I import the layer as singlepart in PostGIS and try to make a multipart version I get errors like:

GEOSUnaryUnion: TopologyException: Input geom 0 is invalid: Hole lies outside shell at or near point 1658834.9461550333 166634.78589000006 at 1658834.9461550333 166634.78589000006

If clean with ST_MakeValid during the singlepart to multipart phase then the operation goes ok.

So, if I:

  • import the layer to postgis as singlepart
  • clean it with ST_Makavalid
  • compute areas of any single feature (of cleaned singlepart layer) and sum by landuse
  • make a multipart version of the layer and compute the areas
  • compare

the differences are very small (down to the 5th decimal place)

but if compute the areas of the unclean singlepart version and compare to the cleaned multipart ones, then there are much bigger differences.

#3 Updated by Giovanni Manghi almost 8 years ago

the areas computed in the shapefile version of the cleaned (with postgis) singlepart vector are the same as the ones computed in postgis.

Then the areas for the multipart version of this shapefile (in this case the singlepart to multipart operation was done with the qgis tool) are not comparable to the ones computed in postgis, there are differences suggesting that even with a supposedly cleaned vector the singlepart to multipart tool does something not expected(?).

#4 Updated by Alexander Bruy almost 7 years ago

  • Status changed from Open to Feedback
  • Category changed from Geometry to Processing/QGIS

I think we can close this as error was caused by invalid geometries.

#5 Updated by Giovanni Manghi almost 7 years ago

  • Easy fix? set to No
  • Regression? set to No

#6 Updated by Giovanni Manghi almost 7 years ago

  • Resolution set to invalid
  • Status changed from Feedback to Closed
  • Description updated (diff)

Also available in: Atom PDF