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

[GRASS GIS]

#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:5 hamish]:
 > Replying to [comment:1 hamish]:
 > > did you try the g.region align=rastermap option?

 This works fine. Nevertheless, what I want to do is a bit more
 complicated:

  * I have X raster and Y point vector maps.[[BR]]
  * Each point vector map has one column for each raster, that is at least
 X columns (+cat +the typical rows, cols columns).[[BR]]
  * I want to update the X columns in each point map with the values from
 the (X) raster maps (one column per raster map of course).[[BR]]


 So what I do in my script is (in pseudocode):
 {{{
 for point_map in group_of_point_maps:
     g.region vect=point_map

         for Raster in group_of_rasters:
             v.what.rast vect=point_map rast=Raster column=Raster
 }}}

 This is where the problem arises since I can't use the align=ToRasterMap
 option. To make the long story short it is required:[[BR]]
  a. to loop over a series of point vector maps whose columns are to be
 updated[[BR]]
  b. to (sub-) loop over a series of raster maps from which the vector
 columns will be updated (for each point vector map).

 How to solve this? Maybe it's a common problem but I don't know how to
 deal with it than just use a basic naming convention for all maps and play
 later with string manipulation utilities (such as cut, tr, sed, etc in
 bash or the likes in python). So, I was thinking that a "better" g.region
 option would make things easier when "align=ToRasterMap" is not an
 option.[[BR]]

 Currently I don't have a problem because, as I described in the very
 beginning, I have the original vector grids from which the point maps
 derived and it's easy to use them (almost same name) in the "g.region"
 command in order to get a larger region.

 Hope this is now clear. Thanks, Nikos

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