[GRASS-user] large shapefile not importing properly with v.import

[Markus Metz]

On to the next one:

On Fri, Oct 20, 2017 at 10:07 PM, Helmut Kudrnovsky <hellik at web.de> 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
> grass-user at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20171023/c1f8d661/attachment.html>