I've added a script [1] with following calculations ideas:
- do some calculations with r.slope.aspect output
- coarse the resolution (but meet the DEM extent)
- do some calculations with r.slope.aspect output at the coarser resolution
- coarse the resolution again (but meet the DEM extent)
- do some calculations with r.slope.aspect output at the again coarser
resolution
- combine all the results for some index calculation
as the extent of the r.slope.aspect output is 1 pixel less then DEM input,
the extent of the calculation output shrinks from one step to the next as
the resolution is coarsening.
I've added a script [1] with following calculations ideas:
- do some calculations with r.slope.aspect output
- coarse the resolution (but meet the DEM extent)
- do some calculations with r.slope.aspect output at the coarser
resolution
- coarse the resolution again (but meet the DEM extent)
- do some calculations with r.slope.aspect output at the again coarser
resolution
- combine all the results for some index calculation
as the extent of the r.slope.aspect output is 1 pixel less then DEM input,
the extent of the calculation output shrinks from one step to the next as
the resolution is coarsening.
On Sat, Jan 3, 2015 at 1:49 PM, Helmut Kudrnovsky <hellik@web.de> wrote:
as the extent of the r.slope.aspect output is 1 pixel less then DEM input,
the extent of the calculation output shrinks from one step to the next as
the resolution is coarsening.
any idea how to overcome such a shrinking?
r.slope.aspect compute the first derivative (1 pixel less) and depends
on the outputs that are selected the second derivative (2 pixels
less), this is not a bug.
I unterstand the same. my question is more about how to implemented the
mentioned iterative algorithm which uses coarser resolution by each step and
how to avoid an extent shrinking of e.g. about 400m with the coarsest
resolution.
you can use r.resamp.rst which computes slope and aspect and does not shrink the region. But you may need to adjust the parameters
to make sure it works well.
Another way would be to modify r.slope.aspect to compute the values at the edges - a second order polynomial min.square approximation
is used to estimate the derivatives in r.slope.aspect (you get the well known differencing function when you do the math) and it can be used
also to compute the values at the edge cells, but I had no luck convincing others that it is the right thing to do.
I believe that any reasonable estimate is better than the current shrinking region (in r.flow we just propagate the same values to the edges),
but that does not seem to be the consensus.
Also, implementation for the edges is not straightforward because of how
GRASS works with rows, but a smart developer could certainly do it (you can compute the edge values e.g.in r.mapcalc).
I hope this clarifies it and may be helps a little bit. I am quite interested in the flat valley bottoms - here in NC they are often
found as bottoms of abandoned, dried out mill ponds.
Helena
Helena Mitasova
Professor at the Department of Marine,
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmitaso@ncsu.edu http://geospatial.ncsu.edu/osgeorel/
"All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.”
On Jan 4, 2015, at 7:54 AM, Helmut Kudrnovsky wrote:
Hi Pietro,
this is not a bug.
I unterstand the same. my question is more about how to implemented the
mentioned iterative algorithm which uses coarser resolution by each step and
how to avoid an extent shrinking of e.g. about 400m with the coarsest
resolution.
I believe that any reasonable estimate is better than the current
shrinking region (in r.flow we just
propagate the same values to the edges), but that does not seem to be the
consensus.
I agree with you that a reasonable estimate is better than the current
situation.
you can use r.resamp.rst which computes slope and aspect and does not
shrink the region. But you may
need to adjust the parameters to make sure it works well.
[...]
(you can compute the edge values e.g.in r.mapcalc).
I'll have a look r.resamp.rst and r.mapcalc in the meantime.
I am quite interested in the flat valley bottoms.
the authors [1] introduced a quite complex procedure to calculate an index
of valley bottom flatness, but it seems to be used especially in soil
science papers. I've used it a little bit for riverine landscape analysis.
in r.valley.bottom [1] DEM coarsening and smoothing as suggested by Gallant
& Dowling seems to work already; although a lot of code tweaking (especially
to choose/calculate thresholds independently of base DEM resolution, ...) is
still needed.
testing and input is welcome.
[1]
"John C. Gallant and Trevor I. Dowling
A multiresolution index of valley bottom flatness for mapping depositional
areas.
WATER RESOURCES RESEARCH, VOL. 39, NO. 12, 1347, doi:10.1029/2002WR001426,
2003"
