<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 15, 2017 at 8:32 AM, Benjamin Ducke <span dir="ltr"><<a href="mailto:benducke@fastmail.fm" target="_blank">benducke@fastmail.fm</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":w1" class="a3s aXjCH m15b71a39e8394682">The thing is: I originally developed this module for<br>
gradiometer data. That data is very noisy and has<br>
high local variation. Interpolating that type of<br>
data while preserving original measurements will<br>
usually result in unsatisfactory output. Also note<br>
that the smoothing increases with the interpolation<br>
radius. For tiny holes in LiDAR data, try "distance=1"<br>
or "2". Of course, LiDAR data probably has different<br>
properties and does not need low-pass filtering<br>
like gradiometer data. So try "-p" to preserve the<br>
original values.<br>
<br>
An alternative would be to invert the behaviour of<br>
the module and assume "-p" by default.<br>
<br>
I don't work with LiDAR data myself, but I would very<br>
interested to know your results!</div></blockquote></div><br><br></div><div class="gmail_extra">I've added a figure which shows the r.slope.aspect products from the surface without and with -p. You can see that the smoothing gives significantly different results and probably better ones. I had the same experience in past when trying to patch result of r.neighbors with the original raster. Perhaps using smaller distance as you say or greater power would help, but I haven't tested that yet.<br><br></div><div class="gmail_extra">I managed to commit just the figure its caption. If somebody gets to it, please extent the section.<br></div></div>