<div dir="ltr"><div><div><div><br><br>On Mon, Oct 23, 2017 at 3:49 PM, Helmut Kudrnovsky <<a href="mailto:hellik@web.de">hellik@web.de</a>> wrote:<br>><br>> Markus Metz-3 wrote<br>> > On to the next one:<br>> ><br>> > On Fri, Oct 20, 2017 at 10:07 PM, Helmut Kudrnovsky <<br>><br>> > hellik@<br>><br>> > > 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>> ><br>> > First problems: lots of warnings like<br>> > WARNING: Degenerate island (1 vertices)<br>> > WARNING: Feature (cat<br>> > <XY><br>> > ): degenerated polygon (1 vertices)<br>> ><br>> > These are invalid geometries in the input<br>> >><br>> >> >The real cleaning happens only if the snap option is set to > 0.<br>> ><br>> > From the WDPA manual:<br>> > "There are many overlapping protected areas in the WDPA. These can be<br>> > overlapping areas with<br>> > different IUCN categories or the overlap of national protected areas with<br>> > designations under<br>> > regional or international conventions and agreements."<br>> ><br>> > Thus I would not regard all overlapping areas as errors. I used a spatial<br>> > subset for testing:<br>> > v.in.ogr spatial=5.467,43.842,14.3,50.558<br>> > that's the Alps and a bit around.<br>> ><br>> > v.in.ogr suggests a snapping value in the range 1e-5, 1e-13. I started<br>> > with<br>> > 1e-9 and got rid of the warnings like<br>> > WARNING: Unable to calculate area centroid<br>> ><br>> > but some incorrect boundaries remained in the output. With snap=1e-8,<br>> > these<br>> > incorrect boundaries disappeared.<br>> ><br>> > The output contains lots of small areas. According to GIS_AREA in the<br>> > attribute table, the smallest areas in the input are larger than 100<br>> > square<br>> > meters, so I cleaned with v.clean tool=rmarea thresh=100, getting rid of<br>> > 60% of all areas in the output.<br>> ><br>> > In earlier years, the WDPA was separated into different shapefiles: one<br>> > for<br>> > marine areas, one for IUCN I-VI, one for all other areas. Now everything<br>> > is<br>> > in one shapefile / GDB. When importing these data, a spatial and an<br>> > attribute filter should be set for v.in.ogr.<br>><br>> thanks for also testing this data set. I'll add some notes in the wiki about<br>> importing these datasets.<br><br></div>Maybe we should revise the messages provided by v.in.ogr and v.import.<br><br></div>Overlapping polygons are not a problem if polygons are indeed overlapping, as in these and other datasets. The message in v.in.ogr needs to be rephrased accordingly and tests for real topological errors (incorrect boundaries, incorrect centroids) need to be added.<br><div><br></div><div>IMHO this is worth a new enhancement ticket, but it should also be
discussed in the user ml to get feedback about how to improve v.import
and v.in.ogr.</div><div><br></div></div>Another problem is that these and other vector datasets provide polygons in one layer that should be (have previously been) provided in separate layers, e.g. different shapefiles. Users need to read the documentation of these datasets (not of GRASS GIS) and then decide what features should be imported.<br><div><div><div><br></div>Markus M<br></div><div><div><br></div><div>><br>> thanks.<br>><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>