Hi Moritz,
thanks for the hacks, they seem very useful!I am not so worried about the speed
right now but more with the "do-ability" of the job.For some of the things I
tried to do I just got stuck on 0 or 3% and the process did not go further, at
least in the simple computers I use.I may try a modification of your code in
the coming weeks, it does not seem so hard indeed. I come back here if can (or
cannot) do it. Thanks!
regardgin the r.patch part, what you mean is that it could be better to have a
calll to the module r.patch instead of to this function "rpatch_map" that is
used in the source code?
BestBernardo
Em quarta-feira, 7 de outubro de 2020 13:08:16 GMT+2, Moritz Lennert
escreveu:
On 7/10/20 12:37, Bernardo Santos wrote:
> Dear community,
>
> I have recently found that some functions such as r.mapcalc and
> r.textile have their "tiled" versions, whichi is perfect for processing
> things in large extents and fine scale resolution.
> I need to perform a moving window analysis, such as using r.neighbors,
> over large areas. Is there already any implementation of a
> "r.neighbors.tiled" or something like that?
> (If not, that would definitely be very useful!)
AFAIK, there is no r.neighbors.tiled. Actually, the two others you cite
were quick hacks from me which I decided to make available in case they
could be useful.
Several tests by others using r.mapcalc.tiled have not shown significant
speed increase, and so there is currently a discussion about how to
solve this (the current idea is to try with r.patch instead of the
internal python-based patching routine). Unfortunately, I don't have
much time for GRASS GIS these days, so will not be able to do anything
about this.
You could have a look at the existing *.tiled modules (see link to the
code at the bottom of the online man page) to see how they work (not
very complicated) and try to cook your own for r.neighbors. :-)
Moritz
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
