Polygon disappears in unaryUnion #965
Comments
|
Weird, I'll look into this. It doesn't happen in JTS. |
|
Looks like the area of the result changed from 517747 in 3.9 to 517642 in 3.10. I can try bisecting on that. |
|
The missing polygons are on the extreme right of the input geometry: 
|
|
While it looks like a single polygon, it's actually 3, one of which is extremely narrow. Perhaps there's a robustness problem causing an exception to be thrown, and somehow the polygons involved are being dropped from the processing as a result of that? However, unioning ONLY those polygons does succeed. 
|
|
Breaking commit is 0b2c29a |
|
It seems that the commit produces a different sequence of pairwise unions, one of which produces an incorrect result both in JTS and GEOS: A B
Result
|
|
The second component of A is a tiny sliver that intersects B:
|
|
Thanks for the analysis, @dbaston . It's possible this is another instance of the OverlayNG robustness issue in locationtech/jts#1000 This issue occurs in part because of situations which pass the (fairly coarse) heuristics in place to detect the failure. I'm thinking about replacing them with an area-based heuristic. That might resolve this case. |
|
@dr-jts I would very much favor the expensive and robust area check you mention in locationtech/jts#1000. These bugs seem to happen quite a lot in the land use dataset I am trying to produce, earlier made with ArcMap. Especially when doing intersection and difference (#942). Rounding the coordinates is not an appealing option in this case, since we can't have gaps between the polygons. I can try to track down some more examples, if this is of interest. I came over this one, which results in two holes in the middle when dissolving in QGIS (GEOS 3.12) and shapely (GEOS 3.11.1), but not in GEOSOP (3.13.0dev). Don't know if this is related. |
The holes in My testing with |
That's a bit of a research project, so not sure when (or if) it will be added. It is also possible to add an envelope-based check, but that probably will only detect a subset of errors. One thing that would help is to remove extremely small-area polygons (slivers) before processing. This won't solve all problems, but might help with some. As per examples in #942 removing spikes would also help - but that will require custom code.
At some point (soon hopefully) I'll be working on a Coverage Cleaning operation. Perhaps that will also help solving this issues. |
|
@dr-jts Yes, the small holes returned from GEOSOP are legitimate, but not the larger ones returned from QGIS/shapely with different GEOS versions (so probably not relevant here). Removing slivers would solve some issues, but it will also leave gaps which would need dissolving later. Maybe an option. Removing spikes is tricky. Are there any good ways to do this other than buffering (which slows things down way too much)? Currently, I am trying to bypass the opposite overlay results by doing both intersection and difference for each overlay operation (then picking the relevant polygons based on intersects of their representative point). This is slow, but seemingly effective. Dissappearing or closed polygons after unaryUnion is harder to guard against. |
Right, I see that in the You seem to have the perfect dataset to expose these errors - unluckily for you! Too bad the original data isn't of higher quality. |
Not really in GEOS at the moment. There are various algorithms around for removing spikes, which could be implemented. In JTS the 
Unfortunately |
|
The original data is of high quality, but we are combining a bunch of datasets, which results in a whole lot of edge cases. Lucky indeed! I cannot really use JTS, since this is all done in Python. But intersesting to hear. Off-topic, out of curiosity: why are JTS and GEOS separate? Do they have different use cases? |
Ah, so the slivers are the result of an overlay?
No, same use case. As you have noticed, the main reason GEOS exists is that it is usable in a lot of places where JTS isn't. It is a separate project for many reasons: different technology, different set of contributors, different governance model. But the projects are pretty tightly linked. Some improvements start in JTS and then are ported into GEOS, and there's also things that go the other way. |
Yes, or about 10-15 overlays. I came across another example where poygons dissappear in shapely and QGIS but not GEOSOP. Are there any changes from GEOS 3.12 to 3.13.0dev that solve some, but not all, of these issues, or is this a QGIS and shapely issue? |
Right, I see that behaviour. I'm not sure what might have changed in 3.13dev to improve this. Possibly #937? Would have to bisect to see if that's the cause of the improvement. If so, that is an excellent result, for the cases it fixes. |
The dissolve_error3.txt dataset is FULL of very narrow sliver polygons. The red below shows all polygons with area < 0.0001: 
It would be good to figure out a way to remove these prior to unioning. That sounds like another coverage cleaning operation (perhaps more tractable than full coverage cleaning, too). |
I have made some functions for cleaning (eliminating slivers, closing gaps, closing small holes), but unary_union is often involved at some point, so it doesn't always fix this problem. Are there other ways to coverage clean? |
|
@dr-jts Not to nag, but I'm just wondering if there will (or might, or will not) be a fix for this of any sort in the next few months? I'm asking since we're publishing this dataset yearly in the spring, hopefully based on GEOS next year. Meanwhile, I'm working on a coverage cleaning/snapping function that almost works, but it's not worth getting it perfect if this is added to JTS then GEOS shortly. |
I think it's unlikely there will be a fix for this in the next few months. It's pretty high priority, but it's also a tough problem to solve. If you have a potential solution in the works, then it's worth pursuing that. |
dr-jts
changed the title
I have a list of polygons where one polygon dissappears after unaryUnion. Tested in geosop with GEOS 3.13.0dev (also tested in shapely with 3.11 and QGIS with 3.12).
The disappearing polygon is this one:
POLYGON ((33668.77730000019 6953106.171599999, 33649.936599999666 6953078.862100001, 33650.19849999994 6953082.8554, 33652.10510000028 6953089.261399999, 33654.99129999988 6953094.7304, 33659.10290000029 6953099.521200001, 33664.003800000064 6953103.493299998, 33668.77730000019 6953106.171599999))
dissolve_error.txt
The text was updated successfully, but these errors were encountered: