<div dir="ltr"><div><div><br><br>On Fri, Oct 20, 2017 at 10:07 PM, Helmut Kudrnovsky <<a href="mailto:hellik@web.de">hellik@web.de</a>> wrote:<br>><br>> >Can you provide examples where v.in.ogr with cleaning/polygon conversion did<br>> not work, but v.in.ogr -c + >v.clean produced better results?<br>><br>> really good data sets with all kind of (topological) mess are (from [correct<br>> and incorrect] overlapping to self intersections etc):<br>><br>> o Natura 2000 data (~ 1GB):<br>><br>> <a href="https://www.eea.europa.eu/data-and-maps/data/natura-8#tab-gis-data">https://www.eea.europa.eu/data-and-maps/data/natura-8#tab-gis-data</a><br><br></div>Apparently, there are a lot of polygons in Natura2000 data that are really overlapping, e.g.<br>SITECODE: UK0030395<br>SITENAME: Southern North Sea<br>with<br>SITECODE: UK0030352<br>SITENAME: Dogger Bank<br><br></div>Maybe some sites have been updated (both spatial delineation and name), but the old versions have not been deleted<br><div><br>v.in.ogr without snapping gives me lots of warnings about</div><div>WARNING: Unable to calculate area centroid<br><div><br></div><div>this is a symptom of floating point precision errors, so I tried v.in.ogr with snapping. With snap=1e-3, these warnings disappeared. Small areas could still be removed with v.clean tool=rmarea. In this example, there are still 75 areas smaller than 100 square meters which are most probably noise.<br></div><div><br></div><div>A hint for snapping: v.in.ogr suggest for these data a range of [1e-08, 1] for suitable snapping values. The exponent thus ranges from -8 to 0. Testing all possible values in this range obviously takes a lot of time.</div><div><br></div><div>You could set low = -8 , high = 0, and set mid to (low + high) / 2 = -4</div><div>Test with snap=1e$mid<br></div><div>If you still get errors, increase: set low to mid, get new mid with (low + high) / 2<br></div><div>else, decrease: set high to mid, get new mid with (low + high) / 2 </div><div>Continue this until you found the threshold were these warnings just disappeared.<br></div><div><br></div><div>Snapping is slow and uses quite a bit of memory because it needs a spatial search tree. The nearest-neighbor tree (kd tree) currently used could do with some more optimization, but I (as the author of that beast) would need quite a bit of time to come up with a faster balancing method.<br></div><div>><br>> o World database of protected areas (~ 1 GB):<br>><br>> <a href="https://www.protectedplanet.net/">https://www.protectedplanet.net/</a><br>><br>> >The real cleaning happens only if the snap option is set to > 0.<br>><br>> v.in.ogr gives some hints about the snap option, sometimes I don't know what<br>> should be the optimal setting.<br>><br>> >noticed that v.in.ogr complains about overlapping areas, which were input<br>> polygons that should not >overlap, but snapping did not help there, instead<br>> I needed to remove small areas afterwards with v.clean.<br>><br>> same experiences here.<br>><br>> >Should the current min_area option of v.in.ogr also be used to remove small<br>> areas in the output?<br>><br>> never used this option:<br>><br>> min_area=float<br>>     Minimum size of area to be imported (square meters)<br>>     Smaller areas and islands are ignored. Should be greater than snap^2<br>>     Default: 0.0001<br>><br>> do you mean the small areas shouldn't be imported or small areas should be<br>> added to the neighbor area with the longest adjacent boundaries?<br></div><div><br></div><div>Thinking about it, small areas should be removed afterwards with v.clean tool=rmarea.</div><div><br></div><div>Markus M<br></div><div>><br>><br>><br>> -----<br>> best regards<br>> Helmut<br>> --<br>> Sent from: <a href="http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html">http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html</a><br>> _______________________________________________<br>> grass-user mailing list<br>> <a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br>> <a href="https://lists.osgeo.org/mailman/listinfo/grass-user">https://lists.osgeo.org/mailman/listinfo/grass-user</a><br><br></div></div></div>