[GRASS-user] Clipping Raster Map

Rich Shepard rshepard at appl-ecosys.com
Fri Jan 1 22:06:13 EST 2010


On Fri, 1 Jan 2010, Hamish wrote:

>> GRASS 6.4.0svn (Oregon):/usr4/grassbase/Oregon >
>> g.region -p
>> projection: 99 (Lambert Conformal Conic)
>> zone:       0
>> datum:      nad83
>> ellipsoid:  grs80
>> north:      1334419.25160578
>> south:      1279151.24118496
>> west:       769192.9282895
>> east:       819255.92362222
> ...
>> nsres:      0.00175298
>> ewres:      0.00133118
>> rows:       31528020
>> cols:       37608092
>> cells:      1185708676737840
>
> 2,750 sq-km at 1mm resolution!
>
> thar's yer problem.

   I ignored this because it was set from the vector files. Certainly, the
northwest corner of Oregon is not 2,750 sq-km, and the source DEM has 10m
resolution; supposed I could devide the rows and columns by 10,000.
Tomorrow, when I log in again and start X I'll get the values from the
source mapset of the DEM. Regardless, ...

> start with 'g.region rast=dem -p' to reset the region to the bounds
> of your master map and zoom from there.

   OK. I'll set the project region to the DEM, note the rows, cols, and
cells, then reset it to the proper bounds.

> anything larger than about 50000x50000 rows x cols starts to lag and
> wants a 64bit OS and lots of hard drive space..

   I've a dual-core AMD Athlon-X2 64-bit but haven't had any reason to
install the 64-bit Slackware instead of the 32-bit version. Besides, I don't
want that resolution for the source DEM in any case.

> well, on the positive side, it is some proof that grass's raster engine
> scales rather well and it is just a matter of throwing faster and faster
> computers at it as they become available!

   That's the Microsoft philosophy.

Rich


More information about the grass-user mailing list