#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.
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). 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@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.
#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
Resolution: | Keywords:
CPU: All | Platform: All
--------------------------+-------------------------
Comment (by mmetz):
Replying to [ticket:3554 hellik]:
> 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.
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@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.
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.
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@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.