Generalization will remove full polygons for high tolerance

I can confirm that this happens with Simplify Polygon Coverage and OJ snapshot r3322.
Douglas Peucler simplification is not guaranteed to preserve the number of polygons http://tsusiatsoftware.net/jts/javadoc/com/vividsolutions/jts/simplify/DouglasPeuckerSimplifier.html
There are another algorithms which keep all the polygons like
http://tsusiatsoftware.net/jts/javadoc/com/vividsolutions/jts/simplify/TopologyPreservingSimplifier.html
I am not sure if our Simplify Polygon Coverage is supposed to preserve the topology or not and if this is a bug or a missing feature.

I used Spatialite and SimplifyPreserveTopology function for my data with good result.

Jukka is right about the difference between DouglasPeuckerSimplifier and TopologyPreservingSimplifier.
However, I don't remember I have seen geometries disappearing with DouglasPeuckerSimplifier.
On the other hand, I just check our Simplify Polygon Coverage plugin and found a flaw which could explain that small polygons disappear (just added some comments in the code of SimplifyPolygonCoveragePlugIn). I've no patch yet and I'll try to find a solution with the help of Stefan.

I made some tests. I had originally 84031 polygons and 28 of them has self-intersections. Simplify Polygon Coverage gave only 82970 simplified polygons in 35 minutes. There were no topology errors in those.
Spatialite (or geos and thus fundamentally JTS) found the same 28 invalid polygons from source data. Function Simplify converted all the 84031 polygons in 15 seconds and in the resultset there were 3663 invalid polygons. Function SimplifyPreserveTopology took 95 seconds and result contained 24 invalid polygons.

People tend to believe that SimplifyPreserveTopology preserves layer topology. However, it preserves topology only feature by feature and the resulting layer may have gaps and overlaps. If OJ will use this JTS function some day I would suggest showing a comment about layer topology for the users.

Thanks for the tests Jukka,

Simplify : did you check that you had 84031 polygons in the result.
SimplifyPreserveTopology : I know there are cases where a small hole finishes out of the exterior ring after simplification. If you have stranger cases, it maybe worth pointing them to Martin.
Simplyfy Polygon Coverage : the flaw I identified is about polygons which have only two edges in the graph, and the simplification of both edges give the same result. The polygon disappears.

Agree to add a warning for simplify plugin. It i more difficult with Analysis>Geometry functions

Both Spatialite functions created 84031 polygons. Of those 3663 were invalid when Simplify was used, and 24 when SimplifyPreserveTopology was used. However, for the latter also the original features had topology errors and SimplifyPreserveTopology seems to be reliable.

I did not even remember that generalization D-P and Preserve Topology can be found from Analysis - Geometry functions because the upper menu level Tools - Generalization meets the eye first.

Just to add my detailed testing of simplifying a 500Mb zip layer. Also, please note that this DP algorithm seems to do really well with the layer level topology support. This is the reason we use it.

Original zip - 30363 polygons 524Mb
Original zip Unioned to remove muli-entries - 30357 polygons 524Mb (manually verified correct)

simp01 - 32853
simp01 - unioned - 29885 out of expected 30357 (16Mb)

simp005 - 34751
simp005 - unioned - 30164 out of expected 30357

simp001 - 40331
simp001 - unioned - 30346 out of expected 30357

simp0005 - 43170
simp0005 - unioned - 30351 out of expected 30357 (65Mb)

simp0001 - 46372
simp0001 unioned- 30356 out of expected 30357 (158Mb)

simp00001 - 46500
simp00001 - unioned - 30357 out of expected 30357 back to original polygon number (400Mb)

One item I forgot to mention is that other tools that have had issues similar in nature have suggested that it occurs when the ring size is less than the tolerance and the entire poly gets wiped rather than ignored.

Hi,
I found another problem in the attribute tranfer.

My dataset :
36673 polygons
36572 simplified polygons only (101 polygon missing)
593 polygons have inherited attributes from a feature which is not the source polygon

I'm on the way to find a solution for both problem.
It will not be 100% robust but should solve most problems.

stay tuned

Michaël

Should be mostly fixed in r3349 (with a peformance penalty of nearly 50%).
Please try it so I can close the ticket.

Original Zip

Simplified001

Simplified001-Unioned

Sorry if this shows as multiple posts... the file uploads keep removing my comments...

The simplification keeps the correct number of polygons now after simplify and union. I have attached 3 files that show an issue. In a multipolygon case, the smaller polygon is getting assigned to a larger nearby polygon when the smaller polygon falls within the bounds of that other polygon.

3 files attached. Original zip, simplified, simplified unioned.

60643 has two polys, the smaller disappears but then gets reassigned the poly from 60827 and 60827 also keeps its duplicate polygon as well. So you will see a hole where the smaller poly disappeared and now you have two overlapping identical polys for 2 different zips.

Hi,

Quite strange ! It would help if you could send the polygons involved in your example, a few polygons around and the tolerance distance you used.

Thanks,

Michaël

ZipsToSimplify file... run .001 tolerance simplification on this

Added small set of zips as file. Just simplify as .001 tolerance and you should see the problem.

Thanks

added a test for this corner case, if you want to check it works on your whole dataset.
Thanks for your help,

Michaël

Sorry, forgot to say, fix is available in 3382+

Looks like a good fix. Nice work.

Thanks

I found another case where a polygon is enclosing and capturing another during simplification of another zip dataset. File attached.

simplify at .001

OK, I completed my previous fix, and this case should now be handled as well,

Thanks for your help,

Michaël

I have run a full simplification on the 500mb zip layer and it looks good at many levels now. I will continue testing this in more detail, but it looks good.

Simplification tests from .01 and smaller are great. We do see reoccurrence of the duplicated (and holes resulting from) zips. uploading a new test case if you want to see it. I am not sure if this reaches the point of oversimplification or even a case you want to handle. But just in case you do, the new zip file showing the issue is there.