[GRASS-dev] Zooming issue in gis manager

[Glynn Clements]

Michael Barton wrote:

> This is very helpful, though I'll have to sort through this and follow-up
> messages to see if and where they can fit into the existing algorithms.
> Thanks much.
> 
> A couple of things bother me that perhaps you could clear up. First is that
> it looks like your examples below and some of the follow-ups assume that
> resolution is always an integer. Although the number of rows and columns
> are, of course, integers, I'm sure that ewres and nsres can take on any
> float value. This makes what you are suggesting more complicated I think.

Oops. In the equations I gave, there should have been some integer
casts, e.g.:

 width  = (width  / ewres + 0.5) * ewres
 height = (height / nsres + 0.5) * nsres

should be:

 width  = (int)(width  / ewres + 0.5) * ewres
 height = (int)(height / nsres + 0.5) * nsres

The bounds and resolution don't have to be integers.

Essentially, width/ewres is the number of columns, so the above
adjusts the width to be an integer multiple of ewres. ewres itself
doesn't have to be an integer.

> The other issue is that even when I take out the -a  flag, d.rast makes some
> kind of adjustments to the way that grid cells are displayed such that they
> appear to be somewhat different sized when you make the resolution=1 grid
> cell and when you make the resolution>>1 (original) grid cell. Maybe this is
> what you are referring to in some places below and other posts.

Yes.

G_get_window() etc ultimately calls G__read_Cell_head_array() to parse
the contents of WIND, $WIND_OVERRIDE, or $GRASS_REGION. In turn, that
calls G_adjust_Cell_head().

G_adjust_Cell_head() recomputes the resolution by dividing the width
and height of the region by the number of columns and rows. Thus, if
the current region (WIND, $WIND_OVERRIDE, or $GRASS_REGION) isn't
valid (i.e. (n-s)/rows != nsres or (e-w)/cols != ewres), the
resolution will automatically be changed accordingly.

The solution is to ensure that the region is always valid, i.e. its
width and height are multiples of the resolution. If you obtained the
bounds from the user (e.g. marking a rectangle on the canvas), you
will have to enforce this requirement somehow.

> Finally, is there any reason that I need to be concerned about the values
> of GRASS_WIDTH and GRASS_HEIGHT for PPM output?

In what sense?

-- 
Glynn Clements <glynn at gclements.plus.com>