Hi there, I do this too and the standard methodology for me is to leave the resolution the same and change the region's borders. Take a look at the manual of g.region for guides on this, but let's say I've got the following:
GRASS 6.4.3svn (EPSG4326_WGS84_ll):~ > g.region -g n=63 s=-63 w=95 e=180 nsres=1.10020395685734e-05 ewres=1.10020399076346e-05 rows=11452422 cols=7725840 cells=88479579984480 Then to reduce the region's size I'd do e.g.: g.region n=50 s=-50 w=100 e=110 That would "shrink" my region down to the area that I'm interested in. HTH! Daniel 2012/11/28 Andranik Hayrapetyan <[email protected]> > I have been trying something like this some time ago, but I could not > define region of a mapset as chunk of the whole region. > I was trying to do that with g.region, but it only resized my map and > didn't "cut" it. > > Is g.region the right tool for this task? > If it is not difficult for you, can you, please, explain the process of > doing " *define the region of each mapset as a chunk of the whole region > * " a bit more detailed. > > > On Wed, Nov 28, 2012 at 1:56 PM, Sylvain Maillard < > [email protected]> wrote: > >> Hi, >> >> for this approach, the best would be to >> (before the multi-process job) >> - put your map into the PERMANENT mapset >> >> (for each process in parallel) >> - make a new mapset for each process >> - define the region of each mapset as a chunk of the whole region >> - make your calculation >> >> (once the process competed) >> - put together all the results (eg, with r.patch) >> >> >> Sylvain >> >> >> >> _______________________________________________ >> grass-user mailing list >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/grass-user >> >> > > _______________________________________________ > grass-user mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-user > >
_______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
