[GRASS-dev] [GRASS GIS] #3554: r.slope.aspect: add flag/functionality to not shrink

[Steven Pawley]

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.giswork at gmail.com>
wrote:

>
>
> On Sun, Apr 29, 2018 at 7:36 AM, Steven Pawley <dr.stevenpawley at 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 <trac at 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 at lists.osgeo.org
> >> https://lists.osgeo.org/mailman/listinfo/grass-dev
> >
> >
> > _______________________________________________
> > grass-dev mailing list
> > grass-dev at lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20180429/85dc2253/attachment.html>