[prev in list] [next in list] [prev in thread] [next in thread]
List: grass-user
Subject: Re: [GRASS-user] Recommendations for v.surf.rst parameters for huge region
From: Anna Petrášová <kratochanna () gmail ! com>
Date: 2020-10-26 17:10:56
Message-ID: CAE0EDEpksm6LWcA=JRWT1VDzsp=qxkkH+CuNQqE6Vuhzh3pOXw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Mon, Oct 26, 2020 at 12:38 PM Eric Patton <eric.r.patton@protonmail.com>
wrote:
> On 20/10/20 10:12PM, Anna Petr=C3=A1=C5=A1ov=C3=A1 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 t=
o
> > increase npmin, but that substantially increases processing time. The
> default
> > npmin is 300, but that is typically unnecessary, npmin 150 is usually o=
k
> 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.lida=
r
> 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 abou=
t
> 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.)
>
Unfortunately, you need to read the manual, I agree it can be confusing. I
have been mostly using v.surf.rst for interpolation and r.fill.stats for
gap filling.
>
> 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.
>
I think r.mblend is for seamless combining higher and lower-resolution
data, to e.g. update lidar with UAS, but your surfaces need to be already
interpolated. Addon r.patch.smooth does something similar, but it's raster
based, so it might run faster, not sure if it is relevant for your use case
though.
Anna
>
> Cheers,
>
> ~ Eric.
>
>
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Mon, Oct 26, 2020 at 12:38 PM Eric Patton <<a \
href="mailto:eric.r.patton@protonmail.com" \
target="_blank">eric.r.patton@protonmail.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">On 20/10/20 10:12PM, Anna Petrášová wrote:<br> \
> Hi,<br> > <br>
> I don't have an answer but couple notes I can now think of:<br>
> <br>
> - Variable density of points may be a problem, I sometimes had that issue \
with<br> > gaps in lidar when it creates visible segments. In that case you need \
to<br> > increase npmin, but that substantially increases processing time. The \
default<br> > npmin is 300, but that is typically unnecessary, npmin 150 is \
usually ok and<br> > runs faster. The segments can be mitigated as well by higher \
tension. I usually<br> > use tension between 20-40. I haven't used smooth \
value larger than 5 I think.<br> > But again, your data are probably quite \
different.<br> > <br>
<br>
Hi Anna, thanks for your comments. My experimentation agrees with the range of<br>
values you mention here. <br>
<br>
> - v.surf.rst is parallelized, you need to compile GRASS with openMP to take<br>
> advantage of that<br>
<br>
Yep, done.<br>
<br>
> - Have you looked at r.fill.stats? I used it for lidar, first r.in.lidar and<br>
> then fill the rest with r.fill.stats, possibly multiple passes to fill \
larger<br> > holes. It uses IDW, and it will be *significantly* faster, although \
v.surf.rst<br> > would probably give you better results in the end.<br>
<br>
I have not tried this module yet, but I will. I am somewhat confused about which<br>
raster fill/interpolation module to use in which circumstance, as there are so<br>
many (there are 6 r.resamp.* modules, 2 r.fill* modules...plus r.neighbours,<br>
r.mapcalc, r.surf.{nnbathy,rst,idw}, r.mblend, \
etc.)<br></blockquote><div><br></div><div>Unfortunately, you need to read the manual, \
I agree it can be confusing. I have been mostly using v.surf.rst for interpolation \
and r.fill.stats for gap filling.</div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <br>
I have been running r.mblend for 10 days now, with no sign or ending in sight.<br>
It is stuck on 'Buffering areas' for the last two days with no progress \
percentage<br> written to the terminal, so I am going to have to kill it. \
<br></blockquote><div><br></div><div>I think r.mblend is for seamless combining \
higher and lower-resolution data, to e.g. update lidar with UAS, but your surfaces \
need to be already interpolated. Addon r.patch.smooth does something similar, but \
it's raster based, so it might run faster, not sure if it is relevant for your \
use case though.</div><div><br></div><div>Anna</div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <br>
Cheers,<br>
<br>
~ Eric.<br>
<br>
</blockquote></div></div>
[Attachment #6 (text/plain)]
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic