[GRASS-user] Overlapping pixels among DEM tiles to compute the LS factor for RUSLE

[Nikos Alexandris]

* Ken Mankoff <mankoff at gmail.com> [2019-01-25 11:50:29 -0800]:

>Hi Nikos,
>
>On 2019-01-25 at 07:18 -0800, Nikos Alexandris <nik at nikosalexandris.net> wrote...
>> A billion-pixel scaled DEM is the main input to compute the slope length
>> and steepness (LS) factor for RUSLE (`r.watershed`), only.
>>
>> Tiling this DEM in tiles of 5K^2 pixels (`r.tile`), appears to be a
>> reasonable approach to parallelise this process.

As I learn more, it seems that it's completely wrong to tile this in
squares and that catchment/basin borders need to be essentially
respected.


>Do you need to parallelise it? I just ran r.watershed on a 4.5 billion-pixel DEM w/o a problem on my laptop and I think it took ~6 hours, but I'm not sure. It might have been closer to 12. I have 32 GB of ram and gave half to the process, but told it to use disk instead of memory via the -m flag:
>
>r.watershed -s -m elevation=phi threshold=1000000 drainage=dir memory=16384 --v --o

I just launched an all-in-one go, ~9e8 pixels finally. RAM is not an
issue here. Let's see the timing.

Thank you dear Ken, Nikos