Split with lines processing tool.
What is the bug or the crash?
So I think this is a bug. I could argue this is the intended behavior.
I have a polygon that is a "donut" - A polygon with a hole in it. I have a series of lines that go from the outside to the inside (but none that cross from one side of the polygon to the other). It will not split. Example:
If I do this (or have this):
It mostly splits. It varies between almost splitting and only splitting using 3 or 4 lines. In this case it left two lines out so I was like 90% successful.
Steps to reproduce the issue
- Have a polygon with a hole in it.
- Draw lines from outside to inside and do not have any lines that cross the entirety of the polygon.
- Run split with lines using the poly as the input layer and lines as the split layer.
- It doesn't split.
Versions
3.32, 3.30, 3.28, 3.26
I'm running Ubuntu 22.04
Supported QGIS version
- [X] I'm running a supported QGIS version according to the roadmap.
New profile
- [X] I tried with a new QGIS profile
Additional context
So I could argue due to the way this is set up - this is expected. If you cycle through the lines and "split" technically I don't have a legitimate split (due to it being a donut). The split with lines algorithm loops through the lines - gets nothing that is a legitimate split and ends. The only legitimate split is when a line traverses the entire polygon.
Except as a whole - it should split. I've tried a geometry collection and still not gotten anywhere.
Anyway - sorry for eating up any valuable time if this isn't a legit bug.
Here was the file I was using: fin.zip
This is an interesting case! In the last example, some splitting lines (2) were tested before the "legitimate" split and failed, but those tested after it (9) have succeeded. Do you have any insight on how other GIS packages behave with those two examples?
I do not - My plan is to give this a shot in postgis and try a few other things - but I haven't gotten to it yet. With a client's data I could "guess" what would happen about 80% of the time using data similar to this. With this example I'm about 50/50 on what will happen.
@uclaros it seems to me the processing algorithm output is not constant even using the very same input layers.... sometimes it is:
sometimes:
or:
and so on...
For comparison, using ArcMap 9.3.1 and the the ET GeoWizards 10.2 "Split / Partition Polygons with Polylines" the resulting geometry is always:
See https://www.ian-ko.com/ET_GeoWizards/UserGuide/partitionPolygonsWithPolylines.htm and https://www.ian-ko.com/ET_GeoWizards/UserGuide/et_geowizards_userguide.htm on how it works.
I just checked in 3.34.1 and it's still not working.
Unfortunately, the issue has not yet been fixed.
@northrivergeo I had trouble using "split feature" on the digitizing toolbar today on a geometry like your example. Splitting from an interior ring across the outer ring, or the other way, would fail every time. I'm assuming that the algorithm will only accept lines that cross the outer ring at least twice, disregarding the interior ring(s) on that check.
Merging some of the lines into groups split without issue for multiple tests (3.34.0-Prizren, categorized style by id).
@agiudiceandrea It appears that every little line that ran before the long vertical line failed and any run after it split the polygon again. It looks to be processing the lines unordered, hence the different results you observed.
So, one workaround is to run the algorithm two times: the first time against using the original polygon layer as input layer and the second time using the output of the first algorithm execution as input layer.
Concerning the first image that doesn't get split at all, trying to use the "split feature" map tool on any of the lines returns a warning that nothing was split
It looks like qgsmaptoolsplitfeatures.cpp would return the same NothingHappened for each of the lines.
Updating the documentation for the tool would be helpful. Something like, "When splitting polygons, each split line must create two or more parts or will be ignored". Maybe add an image for polygons, too.