[GRASS-user] Recommendations for v.surf.rst parameters for huge region

Eric Patton eric.r.patton at protonmail.com
Mon Oct 26 09:46:05 PDT 2020


On 20/10/20 10:12PM, Anna Petrášová wrote:
> Hi,
> 
> I don't have an answer but couple notes I can now think of:
> 
> - Variable density of points may be a problem, I sometimes had that issue with
> gaps in lidar when it creates visible segments. In that case you need to
> increase npmin, but that substantially increases processing time. The default
> npmin is 300, but that is typically unnecessary, npmin 150 is usually ok and
> runs faster. The segments can be mitigated as well by higher tension. I usually
> use tension between 20-40. I haven't used smooth value larger than 5 I think.
> But again, your data are probably quite different.
> 

Hi Anna, thanks for your comments. My experimentation agrees with the range of
values you mention here. 

> - v.surf.rst is parallelized, you need to compile GRASS with openMP to take
> advantage of that

Yep, done.

> - Have you looked at r.fill.stats? I used it for lidar, first r.in.lidar and
> then fill the rest with r.fill.stats, possibly multiple passes to fill larger
> holes. It uses IDW, and it will be *significantly* faster, although v.surf.rst
> would probably give you better results in the end.

I have not tried this module yet, but I will. I am somewhat confused about which
raster fill/interpolation module to use in which circumstance, as there are so
many (there are 6 r.resamp.* modules, 2 r.fill* modules...plus r.neighbours,
r.mapcalc, r.surf.{nnbathy,rst,idw}, r.mblend, etc.)

I have been running r.mblend for 10 days now, with no sign or ending in sight.
It is stuck on 'Buffering areas' for the last two days with no progress percentage
written to the terminal, so I am going to have to kill it. 
  
Cheers,

~ Eric.



More information about the grass-user mailing list