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

[Hamish]

Rich wrote:
> Source metadata:
> 
> Map_Projection:
>         Map_Projection_Name: Lambert Conformal Conic
>         Lambert_Conformal_Conic:
>               Standard_Parallel: 43.000000
>               Standard_Parallel: 45.500000
>              
> Longitude_of_Central_Meridian: -120.500000
> Latitude_of_Projection_Origin: 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

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


after you do the zoom run:
  g.region -p
and see if the resolution has been modified (bounds take precedence by
default). You can use the -a flag to make the resolution have precedence
at the expense of maintaining the exact bounds:
  g.region -a res=

with whatever the original map resolution was.

* take care if the original map's bounds are not exactly divisible by
the resolution. (e.g. n=125 s=75 res=50 rows=1)   then -a does not work
as you might expect.


Hamish