[GRASS-dev] Zooming issue in gis manager

[Michael Barton]

OK. I think I've worked these things out in the version that is now in the
cvs. I made a slight change in how the equations below are done in TclTk to
round them to the nearest integer value.


width  = round(width  / ewres) * ewres
height = round(height / nsres) * nsres

Thanks again for pointing the way to solve this.

Michael

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


> From: Glynn Clements <glynn at gclements.plus.com>
> Date: Fri, 3 Nov 2006 21:49:34 +0000
> To: Michael Barton <michael.barton at asu.edu>
> Cc: grass-dev <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] Zooming issue in gis manager
> 
> 
> 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>