[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