[GRASS5] bug in d.what.rast

[Glynn Clements]

GRASS wrote:

> > > > However, if the intention is to use window rows/cols, there isn't any
> > > > point in passing the map name or mapset to show_utm(). Those values
> > > > are only used to retrieve the map's Cell_head, which is only required
> > > > if you want to report map rows/cols.
> > > 
> > > The map's Cell_head is required to get the boundary of the map.  The row/col
> > > is calculated from this boundary.
> >
> > Sure; but that implies that you should also be using the resolution
> > from the Cell_head, not from the window.
> 
> d.what.rast is certainly not r.what.  If the coordinates of the map itself,
> calculated using the Cell_head resolution, is required, it should be
> implemented in r.what.
> 
> d.what.rast deals with display devices; thus it should be sensitive to the
> resolution of the device not the map.  So, I think that if the device
> resolution is changed, d.what.rast should reflect this change.
> 
> This is the reason why d.what.rast uses the window resolution

By that argument, the origin would be the top-left corner of the
window (region), not of the map.

> (== the device resolution).

The term "device resolution" usually refers to pixels, i.e. the
resolution of the monitor window, not of the GRASS window (region).

In any case, the significance of the values which are output by
"d.what.rast -c" should at least be documented in the manual page, and
probably in the "d.what.rast help" output.

As GRASS normally works in map coordinates (degrees, metres, feet),
and that it automatically scales and translates raster data between
the boundaries/resolution of the map and those of the region, the
terms "rows" and "columns" don't have any single obvious meaning.

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