<div dir="ltr">Thanks Markus for the update to r.slope.aspect, and for the additional info.<div><br></div><div>I just updated the mapcalc part of r.valley.bottom (<span style="color:rgb(0,0,0);font-family:Menlo;font-size:11px">72655)</span>to deal with null values as part of the mapcalc expression. I used the strategy of firstly attempting to replace null pixels in the neighbourhood with their opposite (i.e. mirroring), and if that also results in a null value (i.e. in corners) then the value of the centre pixel is used.</div><div><br></div><div>Steve</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 29, 2018 at 8:30 AM, Markus Metz <span dir="ltr"><<a href="mailto:markus.metz.giswork@gmail.com" target="_blank">markus.metz.giswork@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><br><br>On Sun, Apr 29, 2018 at 7:36 AM, Steven Pawley <<a href="mailto:dr.stevenpawley@gmail.com" target="_blank">dr.stevenpawley@gmail.com</a>> wrote:<br>><br>> Handling of nodata values at raster borders for modules which involve focal functions would be handy to have for several GRASS GIS modules, not just for r.slope.aspect. IMHO r.mapcalc, r.texture, and r.resamp.interp (if using bilinear or cubic resampling) would also benefit from this option (perhaps other tools as well).<br><br></div>r.texture already has the -n flag: Allow NULL cells in a moving window<br></div>r.slope.aspect has a new -e flag: Compute output at edges and near NULL values (same like gdaldem -compute_edges)<br></div>r.mapcalc has the isnull() function and the special operators "&&&" and "|||" handling NULL values<br></div>r.resamp.interp needs to be done for bilinear, bicubic, lanczos, implementation could be relatively easy in the raster library functions<br><div><div><div><br></div><div>Markus M<br></div><div><div><br>> Although some users may be concerned that filling nodata values at raster borders can create edge effects, in most cases the common approaches (such as mirroring, reflecting or wrapping) leave little in the way of an obvious edge effect, and also satisfy what I think are most user's expectations that the output raster will have the same dimensions as the input.<br>><br>> Although a similar effect can be achieved by growing the input raster first, this can be inconvenient when used as part of a complex set of focal function operations. An example is that I have just completed working on an updated r.valley.bottom module, which required multiple r.grow operations as the algorithm repeatedly generalizes the input DEM and calculate flatness and lowness using r.slope.aspect and r.mapcalc focal functions. It also appears that most other tools, including SAGA-GIS, scipy (image filters), and gdaldem provide a method to handle raster borders.<br>><br>><br>> On Sat, Apr 28, 2018 at 2:55 PM GRASS GIS <<a href="mailto:trac@osgeo.org" target="_blank">trac@osgeo.org</a>> wrote:<br>>><br>>> #3554: r.slope.aspect: add flag/functionality to not shrink<br>>> -------------------------+----<wbr>---------------------<br>>> Reporter: hellik | Owner: grass-dev@…<br>>> Type: enhancement | Status: new<br>>> Priority: normal | Milestone: 8.0.0<br>>> Component: Raster | Version: svn-trunk<br>>> Keywords: | CPU: All<br>>> Platform: All |<br>>> -------------------------+----<wbr>---------------------<br>>> at the moment, the result maps of r.slope.aspect, e.g. slope etc, are<br>>> shrinked by 1 pixel.<br>>><br>>> adding a flag/functionality to not shrink the result maps e.g. by adding<br>>> the same value as the -1 off pixel, some interpolations or similar as an<br>>> enhancement.<br>>><br>>> --<br>>> Ticket URL: <<a href="https://trac.osgeo.org/grass/ticket/3554" target="_blank">https://trac.osgeo.org/grass/<wbr>ticket/3554</a>><br>>> GRASS GIS <<a href="https://grass.osgeo.org" target="_blank">https://grass.osgeo.org</a>><br>>><br>>> ______________________________<wbr>_________________<br>>> grass-dev mailing list<br>>> <a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a><br>>> <a href="https://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/grass-dev</a><br>><br>><br>> ______________________________<wbr>_________________<br>> grass-dev mailing list<br>> <a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a><br>> <a href="https://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/grass-dev</a><br><br></div></div></div></div></div>
</blockquote></div><br></div>