Bugs item #3607970, was opened at 2013-03-13 21:12 Message generated for change (Comment added) made by bigrodent You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=679906&aid=3607970&group_id=118054
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General / Other Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sean (bigrodent) Assigned to: Nobody/Anonymous (nobody) Summary: Generalization will remove full polygons for high tolerance Initial Comment: Take for instance a US Zip and set it to .01 or even as low as .0001 and you will end up with less polygons than the original file. You will actually remove full zip codes. As you turn the tolerance down they gradually appear back. Upon physical inspection of the shapefile it is clear that it is the smallest zips in the file that get stripped first. Other opensource tools have this issue as well. ---------------------------------------------------------------------- >Comment By: Sean (bigrodent) Date: 2013-03-28 13:12 Message: 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. ---------------------------------------------------------------------- Comment By: Sean (bigrodent) Date: 2013-03-28 11:20 Message: 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. ---------------------------------------------------------------------- Comment By: michael michaud (michaudm) Date: 2013-03-24 10:46 Message: OK, I completed my previous fix, and this case should now be handled as well, Thanks for your help, Michaël ---------------------------------------------------------------------- Comment By: Sean (bigrodent) Date: 2013-03-22 13:10 Message: I found another case where a polygon is enclosing and capturing another during simplification of another zip dataset. File attached. ---------------------------------------------------------------------- Comment By: Sean (bigrodent) Date: 2013-03-22 11:35 Message: Looks like a good fix. Nice work. Thanks ---------------------------------------------------------------------- Comment By: michael michaud (michaudm) Date: 2013-03-21 00:47 Message: Sorry, forgot to say, fix is available in 3382+ ---------------------------------------------------------------------- Comment By: michael michaud (michaudm) Date: 2013-03-21 00:47 Message: added a test for this corner case, if you want to check it works on your whole dataset. Thanks for your help, Michaël ---------------------------------------------------------------------- Comment By: Sean (bigrodent) Date: 2013-03-19 14:22 Message: Added small set of zips as file. Just simplify as .001 tolerance and you should see the problem. Thanks ---------------------------------------------------------------------- Comment By: michael michaud (michaudm) Date: 2013-03-19 13:48 Message: 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 ---------------------------------------------------------------------- Comment By: Sean (bigrodent) Date: 2013-03-19 11:44 Message: 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. ---------------------------------------------------------------------- Comment By: michael michaud (michaudm) Date: 2013-03-17 02:51 Message: Should be mostly fixed in r3349 (with a peformance penalty of nearly 50%). Please try it so I can close the ticket. ---------------------------------------------------------------------- Comment By: michael michaud (michaudm) Date: 2013-03-16 13:59 Message: 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 ---------------------------------------------------------------------- Comment By: Sean (bigrodent) Date: 2013-03-14 09:09 Message: 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. ---------------------------------------------------------------------- Comment By: Sean (bigrodent) Date: 2013-03-14 09:06 Message: 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) ---------------------------------------------------------------------- Comment By: Jukka Rahkonen (jratike80) Date: 2013-03-14 06:12 Message: 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. ---------------------------------------------------------------------- Comment By: Jukka Rahkonen (jratike80) Date: 2013-03-14 05:46 Message: 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. ---------------------------------------------------------------------- Comment By: michael michaud (michaudm) Date: 2013-03-14 05:30 Message: 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 ---------------------------------------------------------------------- Comment By: Jukka Rahkonen (jratike80) Date: 2013-03-14 02:31 Message: 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. ---------------------------------------------------------------------- Comment By: michael michaud (michaudm) Date: 2013-03-14 00:51 Message: 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. ---------------------------------------------------------------------- Comment By: Jukka Rahkonen (jratike80) Date: 2013-03-13 22:27 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=679906&aid=3607970&group_id=118054 ------------------------------------------------------------------------------ Own the Future-Intel(R) Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
