[GRASS-user] r.slope.aspect: Unexpected Results

[Glynn Clements]

Rich Shepard wrote:

>    I believe that I asked about this before but I don't have the thread
> saved, and I don't know where the mail list is archived.
> 
>    I have a 10m DEM and tried running r.slope.aspect on it. The output files
> (one each for slope and aspect) look like static divided into square cells.
> The same problem occurs when I refine the resolution to 1m. I believe that
> Markus N. wrote a comment about this but I don't have that message.
> 
>    What do I read to learn what the input raster map needs to provide
> r.slope.aspect so that the outputs are appropriate?

First, the current region's grid should at least match that of the
input map, and ideally of the original data.

If the data has been resampled (including projection with r.proj),
this may produce artifacts, particularly if it used method=nearest
(which is the default).

But before you try redoing the projection step, you might want to try
running r.slope.aspect on the "source" data (which may itself be the
result of resampling). If you get similar results, you really need
better source data.

Essentially, slope calculations can be quite sensitive to resampling
artifacts. 

Re-projection from lat/lon with equal latitude and longitude
resolutions is problematic as (unless you're close to the equator) a
degree of longitude represents a smaller distance than a degree of
latitude.

Additionally, most of the processes for acquiring geographic data tend
not to produce values on a regular lat/lon grid, so if your data is on
such a grid, it's quite likely to have been resampled already.

Things which may help:

1. Better (i.e. "uncooked") source data. Reprojecting from the
original grid to the desired target grid in one step is better than
reprojecting to lat/lon then again to the target grid.

2. Upsampling the source data with e.g. r.resamp.interp.

3. Filtering the source data with e.g. r.neighbors or r.mfilter.fp.

4. Re-projecting using method=cubic rather than method=nearest.

5. Filtering the projected data with e.g. r.neighbors or r.mfilter.fp.

You wouldn't want to use *all* of these. #1 is nice if you can get it
(and can use it; you need to know the source "projection"), #4 is safe
(it may not be perfect, but it shouldn't be worse than the other
options), but the others could make matters worse if you don't know
what you're doing.

In the worst case, #5 can be used to get rid of the noise at the
expense of resolution (i.e. you'll end up with slope values which
represent an average over a large area).

-- 
Glynn Clements <glynn at gclements.plus.com>