[GRASS5] bug in d.what.rast

[Glynn Clements]

Roger Miller wrote:

> > The man page says it outputs row/col for the entire map region.  It's
> > a bit ambiguous what that means.  One reason to use the window vs.
> > the actual cell region, is probably because the coordinates derived
> > from a mouse click are based on the display window.  It should be
> > consistent with how the categories are looked up (otherwise, it'd
> > likely report a row/col value that doesn't match the category reported).
> >
> > > 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.
> >
> > Probably should use the monitor's.  In practice, they'll probably
> > be the same as user's aren't likely to change the region setting
> > between drawing the raster and querying it.  Still, if they do,
> > it could lead to interesting results...
> 
> The -c option is intended to give the location in the map, hence it 
> initiailizes the cellhd structure from the raster file.
> 
> Printing the monitor row/col would be a useless result -- at least for my 
> purpose.  The idea is to locate a feature in the map.  I'm not sure what 
> other people use it for, but I use it to locate the row/column location of a 
> feature in a groundwater model where I need to know row and column.  I 
> imagine that other people might have similar uses for it.  I don't think that 
> GRASS offers any other facility to do the same thing.  The location of the 
> feature on the monitor has no value that I can imagine. 

Note that "window" row/col refers to the current window, in the sense
of G_get_window() and the WIND file, not the monitor window (pixel
coordinates).

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