<div dir="ltr"><div><div><div><div>On to the next one:<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>[...]<br>><br>> o World database of protected areas (~ 1 GB):<br>><br>> <a href="https://www.protectedplanet.net/">https://www.protectedplanet.net/</a><br></div><div><br></div><div>First problems: lots of warnings like<br>WARNING: Degenerate island (1 vertices)<br>WARNING: Feature (cat <XY>): degenerated polygon (1 vertices)<br></div><div><br></div><div>These are invalid geometries in the input<br></div><div>><br>> >The real cleaning happens only if the snap option is set to > 0.<br><br></div>From the WDPA manual:<br>"There are many overlapping protected areas in the WDPA. These can be overlapping areas with<br>different IUCN categories or the overlap of national protected areas with designations under<br>regional or international conventions and agreements."<br><br></div>Thus I would not regard all overlapping areas as errors. I used a spatial subset for testing:</div><div>v.in.ogr spatial=5.467,43.842,14.3,50.558</div><div>that's the Alps and a bit around.<br></div><div><br></div><div>v.in.ogr suggests a snapping value in the range 1e-5, 1e-13. I started with 1e-9 and got rid of the warnings like<br>WARNING: Unable to calculate area centroid<br><br></div>but some incorrect boundaries remained in the output. With snap=1e-8, these incorrect boundaries disappeared.<br><br></div>The output contains lots of small areas. According to GIS_AREA in the attribute table, the smallest areas in the input are larger than 100 square meters, so I cleaned with v.clean tool=rmarea thresh=100, getting rid of 60% of all areas in the output.<br><div><div><div><div><br></div><div>In earlier years, the WDPA was separated into different shapefiles: one for marine areas, one for IUCN I-VI, one for all other areas. Now everything is in one shapefile / GDB. When importing these data, a spatial and an attribute filter should be set for v.in.ogr.</div><div><br></div><div>HTH,</div><div><br></div><div>Markus M</div><div><br></div><div>><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>><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></div></div>