Bug report #15377
'Split Features' tool fails to split valid (?) polygon
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Severe/Regression | ||
| Assignee: | - | ||
| Category: | Digitising | ||
| Affected QGIS version: | 2.16.1 | 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 #: | 23307 |
Description
The 'Split Features' tool fails to split the attached sample polygon:
No feature split done: The geometry is invalid. Please repair before trying to split it.
I've performed several geometry checks (self intersection, duplicate node, minimal angle, ...), but the polygon seems to be valid.
15377.zip - shape files (35.1 KB)
screenshot_15377.png - screenshot (146 KB)
test_polygon_buff0.zip (31.8 KB)
test_polygon_ogr.txt 
(84.9 KB)
test_polygon_buff0_ogr.txt
(85 KB)
diff.png (2.29 KB)
hole.png (100 KB)
15377_new.mp4 - screencast (2.92 MB)
15377_new.zip - sample files (11.1 KB)
History
#1
Updated by R. R. over 7 years ago
- File 15377.zip added
- File screenshot_15377.png added
#2
Updated by Saber Razmjooei over 7 years ago
- File test_polygon_buff0.zip added
- Status changed from Open to Feedback
I can't exactly pinpoint the geometry error. But if you buffer it with 0 distance, the split tool starts working on the resultant vector (see attached).
#3
Updated by R. R. over 7 years ago
Splitting the buffered polygon works properly. How should we proceed? Is this a digitizing issue, a geometry checker issue or something else?
#4
Updated by Saber Razmjooei over 7 years ago
- File diff.png added
- File test_polygon_buff0_ogr.txt added
- File test_polygon_ogr.txt added
I have had a close look at the difference between the 2 shapefiles: your original one and output of buffer with 0 distance.
It appears the main differences between the 2 files are "holes" within the shapefile. See the attached ogrinfo text outputs from the 2 files. You can do a diff in a text editor. If you then map some of the vertecies where the 2 files are different, you will see, it happens around the holes.
Did you digitise the original shapefile in QGIS?
#5
Updated by R. R. over 7 years ago
Hi Saber, it seems that splitting the feature fails because of a hole next to the polygon border (see hole.png). How should QGIS deal with this? I have digitised the file in QGIS based on land parcels that came from a .dxf file.
#6
Updated by R. R. over 7 years ago
- File hole.png added
#7
Updated by Saber Razmjooei over 7 years ago
Hi Reinhard, I think this should be picked up by the geometry checker. It seems to be a self-intersecting feature but not. Note that the nodes at the intersection do not share the exact same coordinate and there is a slight decimal differences....which could be the source of the problem.(when you move the node in topo editing mode, it still treats them as seperate nodes)
I did v.clean in grass:
v.clean --overwrite input=test_polygon output=clean type=boundary,area error=test_errors tool=break thresh=0
and the result show intersection of the hole with the exterior polygon.
It seems to be related both to the digitsing tools and geometry checker....leave it to devs to decide.
#8
Updated by R. R. over 7 years ago
- File 15377_new.zip added
- File 15377_new.mp4 added
Thanks for you help! I've uploaded a screencast to demonstrate the issue in a simple manner.
#9
Updated by Giovanni Manghi over 7 years ago
- Status changed from Feedback to Closed
- Resolution set to invalid
Hi Reinhard and Saber,
I really think that in this case the "split features" tool is working the right way, by warning the user that the operation can't be done because the geometry is invalid. If I recall correctly that check was added because otherwise the tool produced wrong results.
The input polygon is indeed invalid, there is a ring self intersection, and this can be easily seen with PostGIS ST_IsValidReason. After fixing it with ST_MakeValid the split operation works as expected.
Fixing this geometries is also easily possible without needing PostGIS, by using the liblwgeom (which is at the base of ST_MakeValid) library and the Processing plugin "liblwgeom provider".
The real issues here are the following:
- QGIS has three (3!) different core tools to check for geometry/topology validity (geometry checker, topology checker and processing/check validity), and only one (geometry checker) of them is able to do some cleaning/fixing. Moreover:
the "geometry checker" can also do some topology check
the "topology checker" can also do some geometry check
the "topology checker" has a set of easy understandable rules, but the message about geometry errors are not verbose enough
the "processing/check validity" is verbose about errors, but is not very robust for large vectors
the "geometry checker" is quite advanced, but maybe too much for the majority of common user who needs to fix its vectors
the 3 tools do not return the same results (what is missed by one tool is sometimes caught by another)
So... the situation is very cluttered... the above tools should be unified, added to the qgis analysis library and exposed to Processing.
and/or...
liblwgeom (the underlying library of ST_MakeValid) is available on all major platforms, and its installation does not implies installing PostGIS. Fixing geometries with such library is as easy as just selecting the input and nothing more, and it works in the vast majority of garbage inputs. Now this approach is available as plugin for Processing. It should be added to QGIS as core functionality in Processing with a tool to clean manually geometries as the plugins does and also as option to automatically clean geometries beforehand before running geoprocessing operations.
While digitizing checks based on liblwgeom should also be enforced.
See: https://github.com/qgis/QGIS/pull/3865
More advanced cleanings could be left to the geometry checker or external resources as GRASS v.clean
Please feel free to comment in the dev mailing list (where I tried to raise the issue, with no success) and/or open new feature request tickets.