<div dir="ltr"><div><div><div><div><div><br><br>On Sun, May 13, 2018 at 7:06 PM, Moritz Lennert <<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>> wrote:<br>><br>> Le Sun, 13 May 2018 17:48:41 +0200,<br>> Hernán De Angelis <<a href="mailto:dhdeangelis@comhem.se">dhdeangelis@comhem.se</a>> a écrit :<br>><br>> > Thanks for your answer and link, Moritz.<br>> ><br>> > Of course, slow or fast are relative terms. May be I wasn't clear<br>> > enough. Let's me explain better:<br>> ><br>> > The core of my processing is simple:<br>> ><br>> > 1. extract point from point map (v.extract)<br>> ><br>> > 2. create buffer (v.buffer)<br>> ><br>> > 3. clip polygon map with buffered point (v.clip)<br>> ><br>> > 4. calculate areas (v.to.db)<br>> ><br>> > This takes only 8 minutes. So we can agree to call it "fast".<br>><br>> 8 minutes for 1 buffer and the 2 million polygons ? And it is step 3<br>> which takes a long time ? I agree that this should be faster. It would<br>> be interesting to understand which part of v.clip takes the longest.<br>><br>> AFAICT, if you clip areas by areas it uses v.overlay so that is<br>> identical with my script. However, by default there is a dissolve step,<br>> unless you use the -d flag. Maybe try with this ?<br>><br>> I imagine that your buffers overlap ? Another option would be to run<br>> v.buffer only once on all points with the -t flag, then v.overlay, then<br>> calculate the areas of overlap between the buffers and the small<br>> polygons and with some SQL magic group the areas by original point cats.<br>><br>><br>><br>><br>> ><br>> > The problem is: I have to do this for 60 points, in 5 different<br>> > buffer sizes, for 14 sets of polygon maps, that is 4200 times.<br>> ><br>> > At this rate, this process will take 4200 x 8 minutes = 33600<br>> > minutes, or about 23 days and 8 hours.<br>><br>> If this approach ends up being the only one, you might be able to<br>> significantly shorten this by parallelizing it.<br>><br>> ><br>> > That's why my question was if there was setting I might activate to<br>> > reduce computation time like, for example, limiting the computational<br>> > region to the area under the buffer. In the meantime since I posted<br>> > my question I read more carefully the v.clip manual and see that<br>> > there is a switch (-r) to use in a defined region. This is what I am<br>> > using now.<br>><br>> Watch out, the -r flag in v.clip means that instead of clipping using<br>> the buffers, you clip your polygons by the rectangle<br>> representing your current computational region. This means you will not<br>> have the area of polygons overlaid by the buffers, but the area that<br>> falls in the current computational region.<br>><br>> ><br>> > I will have a look at your script, but for what I see it does not<br>> > seem critically different from my working routine. I believe I may<br>> > explore another path, namely converting the polygons to a raster of<br>> > suitably small pixel size and calculating the areas using r.stats<br>> > instead. may be that's significantly faster.<br>><br>> r.stats, or r.stats.zonal, or r.univar with the zones parameter, but<br>> for all these the issue is how to handle overlapping buffer areas.<br>><br>> GRASS GIS normally uses a spatial index. This means that overlay<br>> operations of vector features should not have to test in detail all<br>> features, but only those that fall into the relevant bounding boxes.<br>> Maybe there is some issue with this index not being<br>> used ? CC'ing MarkusM who wrote the index code.<br><br></div>You could try to replace <br><br></div>3. v.clip<br><br></div>with<br><br></div>3.1. v.select to select only those areas overlapping with the current buffer<br></div>3.2 v.overlay of the selected areas with the current buffer which should now take only seconds<br><div><div><div><div><div><br></div><div>Markus M <br></div></div></div></div></div></div>