[GRASS-user] Redefining computational region for vector overlay

[Hernán De Angelis]

Hi again Moritz, and thanks for your detailed answer.

Thank you for explaining what the -r switch does in v.clip. Yes, it is 
step 3 that takes long time to complete.

I suspect that the polygon maps may be problematic themselves. When I 
imported them from shapefiles it also took a long time with all the 
cleaning and topology checks.

Unfortunately I do not have much time to explore this in detail now. I 
will try converting to these polygon maps to a raster with small enough 
cell size. That will be fine.

Thanks again for the help!

Cheers!

H.


On 2018-05-13 19:06, Moritz Lennert wrote:
> 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
>