[GRASS-user] r.slope.aspect: Unexpected Results
rshepard at appl-ecosys.com
Tue Jan 26 16:24:34 EST 2010
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.
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_Name: Lambert Conformal Conic
Standard_P arallel: 43.000000
Standard_P arallel: 45.500000
Latitude_of_Projection_O rigin: 41.750000
Planar_Coordinate_Encoding_Method: row and column
Horizontal_Datum_Name: North American Datum of 1983
Ellipsoid_Name: Geodetic Reference System 80
No reprojection necessary.
> Essentially, slope calculations can be quite sensitive to resampling
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
> 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"),
More information about the grass-user