[GRASS-dev] Zooming issue in gis manager

Hamish hamish_nospam at yahoo.com
Fri Nov 3 01:35:02 EST 2006

Glynn Clements wrote:
> I would guess that d.zoom adjusts the bounds manually, whereas gis.m
> uses "g.region -a". The latter does more than just preserve the
> resolution; it also aligns the grid with the coordinate system's
> origin, then aligns the bounds with that grid, rounding outwards (i.e.
> enlarging the region).
> Thus, "panning" (moving the region without changing the e-w or n-s
> differences) with "g.region -a" will change the size of the region if
> the requested bounds aren't aligned to the grid, as it will round
> opposing edges in opposite directions.

here's a little example that demonstrates a problem with the existing
d.zoom, g.region -a:

g.region n=1025 s=-1025 w=-1025 e=1025 res=50
r.mapcalc xy="x()*y()"
r.mapcalc xy_centre="if(abs(xy) < 50000)"
r.to.vect in=xy_centre out=Xy_centre feature=area

r.colors xy rule=ramp
d.rast xy
d.vect Xy_centre type=boundary
d.grid 1000  # note 0,0 crosses middle of cells

d.zoom  # zoom to middle blob
g.region -p
# region is now aligned to 0,0 origin instead of 25,25
# ** data appears "moved" 1/2 a cell in x and y

# 'd.zoom -p' has the same effect
g.region rast=xy
d.zoom -p
g.region -p

# as does 'g.region -a'
g.region rast=xy
g.region res=50 -ap

in this case changing to a resolution of 25 stops the data shift (as a
deadline work-around).


More information about the grass-dev mailing list