On to the next one: On Fri, Oct 20, 2017 at 10:07 PM, Helmut Kudrnovsky <[email protected]> wrote: > [...] > > o World database of protected areas (~ 1 GB): > > https://www.protectedplanet.net/
First problems: lots of warnings like WARNING: Degenerate island (1 vertices) WARNING: Feature (cat <XY>): degenerated polygon (1 vertices) These are invalid geometries in the input > > >The real cleaning happens only if the snap option is set to > 0. >From the WDPA manual: "There are many overlapping protected areas in the WDPA. These can be overlapping areas with different IUCN categories or the overlap of national protected areas with designations under regional or international conventions and agreements." Thus I would not regard all overlapping areas as errors. I used a spatial subset for testing: v.in.ogr spatial=5.467,43.842,14.3,50.558 that's the Alps and a bit around. 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 WARNING: Unable to calculate area centroid but some incorrect boundaries remained in the output. With snap=1e-8, these incorrect boundaries disappeared. 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. 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. HTH, Markus M > > v.in.ogr gives some hints about the snap option, sometimes I don't know what > should be the optimal setting. > > >noticed that v.in.ogr complains about overlapping areas, which were input > polygons that should not >overlap, but snapping did not help there, instead > I needed to remove small areas afterwards with v.clean. > > same experiences here. > > >Should the current min_area option of v.in.ogr also be used to remove small > areas in the output? > > never used this option: > > min_area=float > Minimum size of area to be imported (square meters) > Smaller areas and islands are ignored. Should be greater than snap^2 > Default: 0.0001 > > do you mean the small areas shouldn't be imported or small areas should be > added to the neighbor area with the longest adjacent boundaries? > > > > ----- > best regards > Helmut > -- > Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html > _______________________________________________ > grass-user mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/grass-user
_______________________________________________ grass-user mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/grass-user
