Rich Shepard wrote:
It's possible that the cropping may have changed the grid slightly.
Glynn,
I do hope it's something simple. I can't do more until I have a good DEM
map for the project area.
What are the grid parameters (bounds, resolution, rows/cols) for the
source map and
Glynn Clements wrote:
Rich Shepard wrote:
Source map (demNW raster map):
nsres: 32.82281055
ewres: 32.82281055
Resolution in feet.
Cropped map (abernethy vector boundary map):
nsres: 4.99982001
ewres: 4.99979979
Markus Metz wrote:
I don't think it is possible to have different units within the same
location because units are set globally in PERMANENT/PROJ_UNITS. Is it?
Correct.
Apparently the issue has been reolved. Which is fortunate; as the
previous post doesn't actually make much sense.
--
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
On Tue, 26 Jan 2010, Rich Shepard wrote:
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
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
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
On Tue, 26 Jan 2010, Glynn Clements wrote:
2. Upsampling the source data with e.g. r.resamp.interp.
Glynn,
When would one use r.resamp.interp and when r.resamp.rst? The latter
incorporates functions of r.slope.aspect with the resampling/resolution
change, but what decision criteria guide
Rich Shepard wrote:
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.
It's possible that the cropping may
Rich wrote:
Source metadata:
Map_Projection:
Map_Projection_Name: Lambert Conformal Conic
Lambert_Conformal_Conic:
Standard_Parallel: 43.00
Standard_Parallel: 45.50
Longitude_of_Central_Meridian: -120.50
On Tue, 26 Jan 2010, Glynn Clements wrote:
It's possible that the cropping may have changed the grid slightly.
Glynn,
I do hope it's something simple. I can't do more until I have a good DEM
map for the project area.
What are the grid parameters (bounds, resolution, rows/cols) for the
On Tue, 26 Jan 2010, Glynn Clements wrote:
You could try repeating the cropping process, using g.region's align=
option to align the grid to the source map.
Now I cannot find my notes on how I cropped the larger DEM to the boundary
of the project area. I know that v.overlay works on two
On Tue, 26 Jan 2010, Rich Shepard wrote:
Now I cannot find my notes on how I cropped the larger DEM to the
boundary of the project area. I know that v.overlay works on two vector
maps but ... I've dropped the ball on that operation.
Found it!
r.mapcalc newmap=oldmap
Rich
On Tue, 26 Jan 2010, Glynn Clements wrote:
You could try repeating the cropping process, using g.region's align=
option to align the grid to the source map.
Glynn,
FIXED the problem.
I re-ran 'r.mapcalc aberDEM=demNW' and it cleaned up all the problems.
r.slope.aspect produces output
14 matches
Mail list logo
