[GRASS-dev] what does zoom= do?

Hamish hamish_b at yahoo.com
Mon Jan 28 02:38:34 EST 2008


Hamish:
> Now what does 'g.region align=' do?

Michael:
> This one I can answer. When you zoom, g.region has to maintain an  
> integer number of rows and columns. Without -a, it will find the  
> nearest integer for the rows and columns given the extents and  
> resolution specified. Then it will slightly adjust the resolution so  
> that the specified extents are exactly divisible by the calculated  
> integer number or rows and columns.
> 
> With -a, g.region will slightly adjust the extents (instead of the  
> resolution) to come up with an integer number or rows and columns as  
> close as possible to the selected extents while exactly maintaining  
> the specified resolution.
> 
> Try it by running g.region -ugp after setting a region to specified  
> extents and resolution with and without -a. Without -a, the  
> resolution will differ slightly from those specified, but the extents  
> will exactly match those specified. With -a, the resolution will  
> exactly match and the extents will differ slightly.

That's related, but I was asking about 'align=' not '-a'.

Apparently it works like -a but for the resolution of the specified raster
map, not the current region settings. Region bounds are rounded outward
if needed.

The g.region man page has now been modernized and cleaned and the
module's option descriptions changed to:  (in trunk)

  zoom   Shrink region until it meets non-NULL data from this raster map
 align   Adjust region cells to cleanly align with this raster map


'-a' description kept as-was:

  -a   Align region to resolution (default = align to bounds, works
       only for 2D resolution)

see the new version of the page for the extended explanation.


Michael: 
> However, -a is ignored if the resolution is not specified. I asked  
> that in circumstances where resolution is not specified and -a is  
> used, g.region align to the current resolution, whatever it is.

Sounds reasonable.

If otherwise '-a' is specified but not going to work, we could have it
throw a G_fatal_error() stating that '-a' needs resolution hinting from
somewhere. The thinking being that it's better in the long run to have it
be (verbosely) picky about its input versus it silently doing something
you didn't expect.
??

> Michael wrote:
> > Currently, if you use the -a flag with g.region it will align the  
> > region exactly to match the resolution of a map (e.g. g.region -a  
> > rast=myrast will set the region to exactly the resolution of myrast  
> > regardless of the extents) or the resolution specified in the res or  
> > ewres/nwres fields (e.g. g.region -a n=523 s=15 res=10 will adjust  
> > the extents a little to make sure the resolution is exactly 10).
> > 
> > However, -a is ignored if the map argument (rast=) or resolution  
> > arguments are blank.
Glynn:
> Actually, you need either vect= or res= (or nsres= or ewres=). rast=
> doesn't have any effect. Also, the interpretation is different for
> vect= compared to the resolution options.
Michael:
> > This means that if you want to change the  
> > extents and keep your current resolution, you need to specify the -a  
> > flag AND explicitly specify the resolution. Otherwise, the
> > resolution will be adjusted slightly.
> > 
> > Could this be modified so that when the -a flag is used and  
> > resolution is NOT specified and a map is NOT specified (i.e., only  
> > changing extents) it aligns to the current resolution? That is,  
> > respect the -a flag when res/ewres/nsres= is blank and rast= is blank.
Glynn:
> It would be possible to implement the -a flag unconditionally,
> although you would need to exclude the cases which already have a
> defined meaning (e.g. "g.region -a nsres=..." only aligns the top and
> bottom edges, leaving the left and right edges unchanged).

I prefer to use '-a' on an as-needed basis.

For example- I use a 3rd party model which takes DEM input with data
given for cell centers (same as grass) and bounds defined along grid
lines. But the output is given using the cell-center as coordinate
convention. Don't ask me why. To get everything to line up correctly
after reimport into GRASS, I have to set the region bounds to be half a
cell inward or the data gets translated (resampled) by 1/2 a cell in both
x and y directions.

e.g. processing at 50m resolution:

g.region n=10000 s=0 w=0 e=10000 res=50
r.out.ascii dem ...

## model runs

g.region n=9975 s=25 w=25 e=9975 res=50
# ** -a at this step would align to "00" and "50" not "25" and "75" **
r.in.ascii results...

# at this point I find the easiest thing is to double the res rather
# than fight the offset
g.region res=25
d.rast ..
d.vect ..
# lines up nicely.



Hamish


More information about the grass-dev mailing list