[GRASS5] bug in d.what.rast

[Glynn Clements]

Eric G. Miller wrote:

> > d.what.rast in GRASS pre2 is broken.  The -c flag produces incorrect
> > results.  The problem was introduced somewhere between beta11 and
> > pre2.  The beta11 version works.  I did track down exactly what the
> > problem was, and it looks like it's still there in the current
> > version.
> > 
> > Briefly, the definition of the show_utm function was modified to pass
> > the name of the mapset as an argument.  That causes show_utm to skip
> > the call to G_get_cellhd that fills the cellhd structure; the column
> > and row numbers are then calculated on the basis of  cellhd.north =
> > cellhd.west = 0.
> > 
> > The easiest solution is just to revert the code to the earlier
> > version.
> 
> The changelog seems to indicate there was a problem before.  So,
> maybe what's needed is just to move the G_get_cellhd() function
> call after the if(!mapset){...}, which seems to be the error..
> I'm not sure if there's a good reason for cellhd to be static
> either... ??

In the previous version, mapset was always NULL the first time that
show_utm() was called, ensuring that the Cell_head was read. 
Thereafter, mapset would be non-NULL, and the existing Cell_head would
be read.

So, the bug was introduced in 1.4, and the fix is to always call
G_get_cellhd(). And there isn't any reason for cellhd to be static
now.

Also, I'm suspicious of Huidae's "fix" in 1.3:

-    n_row = (int) ((cellhd.north - north) / cellhd.ns_res);
-    e_col = (int) ((east - cellhd.west) / cellhd.ew_res);
+    n_row = (int) ((cellhd.north - north) / window->ns_res);
+    e_col = (int) ((east - cellhd.west) / window->ew_res);

Either of:

	n_row = (int) ((cellhd.north - north) / cellhd.ns_res);
	e_col = (int) ((east - cellhd.west) / cellhd.ew_res);
and:
	n_row = (int) ((window->north - north) / window->ns_res);
	e_col = (int) ((east - window->west) / window->ew_res);

make sense, depending upon whether you want coordinates in map cells
or window cells. But I can't see any obvious significance to the
values returned by the existing code.

Another question springs to mind, namely whether d.what.rast should
read the region from the monitor rather than using the current window,
as the monitor's region reflects what is actually displayed in the
window.

-- 
Glynn Clements <glynn.clements at virgin.net>