[GRASS-user] Redefining computational region for vector overlay

[Moritz Lennert]

Le Sun, 13 May 2018 17:48:41 +0200,
Hernán De Angelis <dhdeangelis at comhem.se> a écrit :

> Thanks for your answer and link, Moritz.
> 
> Of course, slow or fast are relative terms. May be I wasn't clear 
> enough. Let's me explain better:
> 
> The core of my processing is simple:
> 
> 1. extract point from point map (v.extract)
> 
> 2. create buffer (v.buffer)
> 
> 3. clip polygon map with buffered point (v.clip)
> 
> 4. calculate areas (v.to.db)
> 
> This takes only 8 minutes. So we can agree to call it "fast".

8 minutes for 1 buffer and the 2 million polygons ? And it is step 3
which takes a long time ? I agree that this should be faster. It would
be interesting to understand which part of v.clip takes the longest.

AFAICT, if you clip areas by areas it uses v.overlay so that is
identical with my script. However, by default there is a dissolve step,
unless you use the -d flag. Maybe try with this ?

I imagine that your buffers overlap ? Another option would be to run
v.buffer only once on all points with the -t flag, then v.overlay, then
calculate the areas of overlap between the buffers and the small
polygons and with some SQL magic group the areas by original point cats.




> 
> The problem is: I have to do this for 60 points, in 5 different
> buffer sizes, for 14 sets of polygon maps, that is 4200 times.
> 
> At this rate, this process will take 4200 x 8 minutes = 33600
> minutes, or about 23 days and 8 hours.

If this approach ends up being the only one, you might be able to
significantly shorten this by parallelizing it.

> 
> That's why my question was if there was setting I might activate to 
> reduce computation time like, for example, limiting the computational 
> region to the area under the buffer. In the meantime since I posted
> my question I read more carefully the v.clip manual and see that
> there is a switch (-r) to use in a defined region. This is what I am
> using now.

Watch out, the -r flag in v.clip means that instead of clipping using
the buffers, you clip your polygons by the rectangle
representing your current computational region. This means you will not
have the area of polygons overlaid by the buffers, but the area that
falls in the current computational region.

> 
> I will have a look at your script, but for what I see it does not
> seem critically different from my working routine. I believe I may
> explore another path, namely converting the polygons to a raster of
> suitably small pixel size and calculating the areas using r.stats
> instead. may be that's significantly faster.

r.stats, or r.stats.zonal, or r.univar with the zones parameter, but
for all these the issue is how to handle overlapping buffer areas.

GRASS GIS normally uses a spatial index. This means that overlay
operations of vector features should not have to test in detail all
features, but only those that fall into the relevant bounding boxes.
Maybe there is some issue with this index not being
used ? CC'ing MarkusM who wrote the index code.

Moritz