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

[Rich Shepard]

On Tue, 26 Jan 2010, Glynn Clements wrote:

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

Glynn,

   The number of rows and columns has been changed but not the resolution. At
least, not deliberately.

> 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).

   Nope. Source metadata:

Map_Projection:
         Map_Projection_Name: Lambert Conformal Conic
         Lambert_Conformal_Conic:
               Standard_P arallel: 43.000000
               Standard_P arallel: 45.500000
               Longitude_of_Central_Meridian: -120.500000
               Latitude_of_Projection_O rigin: 41.750000
               False_Easting: 1312336.000000
               False_Northing: 0.000000
Planar_Coordinate_Information:
         Planar_Coordinate_Encoding_Method: row and column
         Coordinate_Representation:
               Abscissa_Resolution: 32.828670
               Ordinate_Resolution: 32.828670
         Planar_Distance_Units: User_Defined_Unit
Geodetic_Model:
 	Horizontal_Datum_Name: North American Datum of 1983
 	Ellipsoid_Name: Geodetic Reference System 80
 	Semi-major_Axis: 6378137.000000
 	Denominator_of_Flattening_Ratio: 298.257222

   No reprojection necessary.

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

   So I understand.

> 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.

   The source originally-imported DEM produces appropriate slope and aspect
maps. The sub-region I cut out with v.in.region (I believe that's the module
I used) doesn't calculate properly. Therefore, the problem is with the
sub-map.

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

   I'll try this on the sub-map.

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

   Source data are OK.

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

   Data came as LCC; no reprojecting needed.

> 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"),

   See above.

Rich