<HTML>
<HEAD>
<TITLE>Zooming issue in gis manager</TITLE>
</HEAD>
<BODY>
<FONT SIZE="2"><FONT FACE="Monaco, Courier New"><SPAN STYLE='font-size:10.0px'>Before we make these changes, I'd like to reiterate again what is going on with a bit of visual display to better show the issues. <BR>
<BR>
1. There is not a systematic, major inaccuracy from zooming the display in the GIS Manager.<BR>
<BR>
2. This inaccuracy reported only occurs with interactive zooming when displaying a raster map so that the raster grid squares are much larger than the pixel size. That is, when you can see only a few grid squares in the display.<BR>
<BR>
3. It affects the number of grid cells displayed, not the actual computational or display regions.<BR>
<BR>
4. It is primarily (or likely entirely) a function of using g.region -a to align the display region to the raster grid at the current resolution. I originally did NOT use this flag, because I was concerned about potentially uncontrolled changes to zoom precision, but added this to the zooming a few months back at the request of others. <BR>
<BR>
Please note the screen shots links below to help document this issue. These pretty much reconstruct the original steps to show the problem, but without region alignment.<BR>
<BR>
First, I took out the -a switch from the g.region command in mapcanvas.tcl<BR>
<BR>
Then I interactively zoomed (zoom box) the spearfish erosion map to show 7 rows by 13 columns<BR>
<BR>
This is shown in <a href="http://www.public.asu.edu/~cmbarton/files/grass_screenshots/display1.jpg"><http://www.public.asu.edu/~cmbarton/files/grass_screenshots/display1.jpg></a><BR>
<BR>
<BR>
I then selected "save current region to match display" to make the WIND file match the display region set interactively with the zoom.<BR>
<BR>
I next selected "display region settings" from the menu <BR>
<BR>
This can be seen in <a href="http://www.public.asu.edu/~cmbarton/files/grass_screenshots/output.jpg"><http://www.public.asu.edu/~cmbarton/files/grass_screenshots/output.jpg></a><BR>
<BR>
Next, I switched to query mode and clicked the NW and SE corners of the display<BR>
<BR>
This can also be seen in output.jpg. Note that the xy values match those in the region extents output (within the small error of a mouse click)<BR>
<BR>
Finally, I selected "zoom to current region" to redraw the screen and make the display match the WIND file<BR>
<BR>
This can be seen in <a href="http://www.public.asu.edu/~cmbarton/files/grass_screenshots/display2.jpg"><http://www.public.asu.edu/~cmbarton/files/grass_screenshots/display2.jpg></a><BR>
<BR>
Note that display1.jpg and display2.jpg are identical. <BR>
<BR>
<BR>
*****************<BR>
The reported problem with displaying grid cells at high magnification is primarily or entirely a function of how g.region -a aligns the region with the raster grid cell boundaries. I don't know how this works internally and someone with C programming experience will have to deal with it if we want it to work differently<BR>
<BR>
So, what do we want to do? We can either have<BR>
<BR>
1. All zooming is aligned with the cell borders, matching the current resolution, with the possible result of a bit of rounding error in the display when zoomed in to a point where the cells are very large compared to pixel size--due to the way that g.region -a works.<BR>
<BR>
OR<BR>
<BR>
2. Zooming is NOT aligned with the cell borders and the current resolution. In this case, what you see is very close to the actual region extents when zoomed in to a point where the cells are very large compared to pixel size. This is how I originally had it.<BR>
<BR>
Note that if you are NOT zoomed in to a point where grid cells look very large compared with pixels (i.e., most the the time in most maps), then the displays appear identical whether the region is aligned to the cell borders or not.<BR>
<BR>
We cannot have it both ways given how g.region -a works. That is, the underlying zoom math is correct and the same in both cases, but can either zoom with g.region -a or with g.region (without the -a flag).<BR>
<BR>
Michael<BR>
__________________________________________<BR>
Michael Barton, Professor of Anthropology<BR>
School of Human Evolution & Social Change <BR>
Center for Social Dynamics & Complexity<BR>
Arizona State University<BR>
<BR>
phone: 480-965-6213<BR>
fax: 480-965-7671<BR>
www: <FONT COLOR="#0000FF"><U><a href="http://www.public.asu.edu/~cmbarton">http://www.public.asu.edu/~cmbarton</a></U></FONT> <BR>
<BR>
<BR>
<BR>
> From: Hamish <<FONT COLOR="#0000FF"><U>hamish_nospam@yahoo.com</U></FONT>><BR>
> Date: Tue, 31 Oct 2006 15:13:43 +1300<BR>
> To: Maciej Sieczka <<FONT COLOR="#0000FF"><U>tutey@o2.pl</U></FONT>><BR>
> Cc: <<FONT COLOR="#0000FF"><U>mlennert@club.worldonline.be</U></FONT>>, <<FONT COLOR="#0000FF"><U>michael.barton@asu.edu</U></FONT>>, <BR>
> <<FONT COLOR="#0000FF"><U>grass-dev@grass.itc.it</U></FONT>><BR>
> Subject: Re: [GRASS-dev] d.m/d.gis mysteries..<BR>
> <BR>
> Maciej Sieczka wrote:<BR>
>> I, personally, would even prefer d.m as the default GUI back,<BR>
> <BR>
> <BR>
> with a mind to making long term users happy, and making the wxpython<BR>
> development easier, I'd like to extend the GRASS_GUI variable.<BR>
> <BR>
> currently it is both a startup shell variable and a GRASS gisenv<BR>
> variable. (if it exists, the former sets the latter at startup)<BR>
> <BR>
> currently you can do<BR>
> <BR>
> GRASS_GUI=text grass63<BR>
> or<BR>
> grass63 -text<BR>
> <BR>
> to start with the command line one<BR>
> <BR>
> GRASS_GUI=tcltk grass63<BR>
> or<BR>
> grass63 -gui<BR>
> or<BR>
> grass63 -tcltk<BR>
> <BR>
> to start with the Tcl/Tk startup + gis.m<BR>
> <BR>
> <BR>
> <BR>
> with this patch you can also do<BR>
> <BR>
> grass63 -oldgui # for d.m<BR>
> <BR>
> or<BR>
> <BR>
> GRASS_GUI=d.m grass63<BR>
> <BR>
> or<BR>
> <BR>
> GRASS_GUI=gis.m grass63<BR>
> <BR>
> or even<BR>
> <BR>
> # rename it to whatever the wxpython GUI will be called<BR>
> GRASS_GUI=wxpython grass63<BR>
> <BR>
> when wx becomes the default just switch "grass63 -gui" to that target.<BR>
> <BR>
> <BR>
> grass remembers the last one you used and uses that as the default.<BR>
> <BR>
> <BR>
> WRT, d.zoom & gis.m zooming- the x monitors and d.zoom have had more<BR>
> than a decade of heavy use to become mature. gis.m has had barely 9<BR>
> months of developer testing to become mature. And even then, most of the<BR>
> long-time developers who hold the bulk of the "institutional knowledge"<BR>
> only work from the command line.... it is really great that it has come<BR>
> so far so fast.<BR>
> <BR>
> the zooming stuff is tricky business- even after all this time d.zoom<BR>
> still has some problems and is far from elegant. accurate rendering &<BR>
> point placement is the bread and butter of a GIS though, so it'd be nice<BR>
> to have everyone happy with gis.m in the long term. Folks will be<BR>
> picking points off the screen and writing down coordinates for their<BR>
> field sites. All the time spent now perfecting the design choices will<BR>
> pay off well, I am sure. Even if only for when we do the wxPython<BR>
> version we can pick the best choices the first time.<BR>
> <BR>
> <BR>
> choices are good,<BR>
> Hamish<BR>
<BR>
</SPAN></FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'><BR>
__________________________________________<BR>
Michael Barton, Professor of Anthropology<BR>
School of Human Evolution & Social Change <BR>
Center for Social Dynamics & Complexity<BR>
Arizona State University<BR>
<BR>
phone: 480-965-6213<BR>
fax: 480-965-7671<BR>
www: <a href="http://www.public.asu.edu/~cmbarton">http://www.public.asu.edu/~cmbarton</a> <BR>
<BR>
</SPAN></FONT>
</BODY>
</HTML>