Thanks Markus for the update to r.slope.aspect, and for the additional info.
I just updated the mapcalc part of r.valley.bottom (72655)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. Steve On Sun, Apr 29, 2018 at 8:30 AM, Markus Metz <markus.metz.gisw...@gmail.com> wrote: > > > On Sun, Apr 29, 2018 at 7:36 AM, Steven Pawley <dr.stevenpaw...@gmail.com> > wrote: > > > > 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). > > r.texture already has the -n flag: Allow NULL cells in a moving window > r.slope.aspect has a new -e flag: Compute output at edges and near NULL > values (same like gdaldem -compute_edges) > r.mapcalc has the isnull() function and the special operators "&&&" and > "|||" handling NULL values > r.resamp.interp needs to be done for bilinear, bicubic, lanczos, > implementation could be relatively easy in the raster library functions > > Markus M > > > 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. > > > > 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. > > > > > > On Sat, Apr 28, 2018 at 2:55 PM GRASS GIS <t...@osgeo.org> wrote: > >> > >> #3554: r.slope.aspect: add flag/functionality to not shrink > >> -------------------------+------------------------- > >> Reporter: hellik | Owner: grass-dev@… > >> Type: enhancement | Status: new > >> Priority: normal | Milestone: 8.0.0 > >> Component: Raster | Version: svn-trunk > >> Keywords: | CPU: All > >> Platform: All | > >> -------------------------+------------------------- > >> at the moment, the result maps of r.slope.aspect, e.g. slope etc, are > >> shrinked by 1 pixel. > >> > >> adding a flag/functionality to not shrink the result maps e.g. by > adding > >> the same value as the -1 off pixel, some interpolations or similar as > an > >> enhancement. > >> > >> -- > >> Ticket URL: <https://trac.osgeo.org/grass/ticket/3554> > >> GRASS GIS <https://grass.osgeo.org> > >> > >> _______________________________________________ > >> grass-dev mailing list > >> grass-dev@lists.osgeo.org > >> https://lists.osgeo.org/mailman/listinfo/grass-dev > > > > > > _______________________________________________ > > grass-dev mailing list > > grass-dev@lists.osgeo.org > > https://lists.osgeo.org/mailman/listinfo/grass-dev > >
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev