[GRASS-user] Redefining computational region for vector overlay

[Markus Metz]

On Sun, May 13, 2018 at 7:06 PM, Moritz Lennert <
mlennert at club.worldonline.be> 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.

You could try to replace

3. v.clip

with

3.1. v.select to select only those areas overlapping with the current buffer
3.2 v.overlay of the selected areas with the current buffer which should
now take only seconds

Markus M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20180513/79015dda/attachment.html>