[GRASS-dev] Re: [GRASS GIS] #789: g.region option to expand the computational region of about "some" pixels?

GRASS GIS trac at osgeo.org
Thu Oct 15 04:18:21 EDT 2009

#789: g.region option to expand the computational region of about "some" pixels?
  Reporter:  nikos        |       Owner:  grass-dev at lists.osgeo.org            
      Type:  enhancement  |      Status:  new                                  
  Priority:  normal       |   Milestone:  7.0.0                                
 Component:  default      |     Version:  unspecified                          
Resolution:               |    Keywords:  g.region, expand computational region
  Platform:  Unspecified  |         Cpu:  Unspecified                          
Comment (by nikos):

 Replying to [comment:1 hamish]:
 > did you try the g.region align=rastermap option?
 > fwiw, -a grows outwards.
 > > Matching the region over a point map is the problem! The
 > > points at the borders (happens quite often to me when the
 > > resolution of the raster map is low and so does the
 > > resolution of the region successively) are not taken
 > > into account.
 > could you explain that more? I don't understand it.

 a. Imagine a point-grid (i.e. points or centroids that would form a square
 if connected)[[BR]]
 b. match the region over this point-grid (g.region -a vect=point-grid #
 the points at the edges are just to be seen when drawing the vector point-
 grid with d.vect for example).[[BR]]
 c. The points at the edges are ignored by v.what.rast vector=point-grid

 > can you provide an example using Spearfish's bugsites + elevation.dem or
 something from the NC standard dataset?

 Right. I'll try to re-produce this in Spearfish.

 > fwiw the region growing I've done has always been for cosmetic reasons.
 in those cases usually make the res=res*2 (or 10) with the -a flag, then
 run g.region again with the original region value.

 Would this (res=res*X) affect v.what.rast?[[BR]]

 (Please, wait till I provide a Spearfish example. No reason to comment
 more on this. Also, the "trick" is an optimal solution I think. Have to
 try this out.)

Ticket URL: <http://trac.osgeo.org/grass/ticket/789#comment:3>
GRASS GIS <http://grass.osgeo.org>

More information about the grass-dev mailing list