[GRASS5] bug in d.what.rast

[GRASS]

> From glynn.clements at virgin.net Mon Mar  4 11:37:08 2002
> From: Glynn Clements <glynn.clements at virgin.net>
> Date: Mon, 4 Mar 2002 02:12:34 +0000
> To: GRASS <grass at geni.cemtlo.com>
> Cc: grass5 at grass.itc.it
> Subject: Re: [GRASS5] bug in d.what.rast
>
>
> GRASS wrote:
>
> > -c bug fixed.
>
> Only in the head; the release branch still has the old version.
>
> > > > > 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);
> > 
> > It is different if the window's resolution is changed by "g.region *res=".
>
> I know; but:
>
> > > > > 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.
>
> > -c option was designed to get the row/col of the map for non-GRASS models.
> > It was difficult to get the coordinates of the interesting points, which do
> > not have any info to get the locations, by counting cells.
>
> In which case, it should probably be using cellhd.{ns,ew}_res, and not
> window->{ns,ew}_res.
>
> > > 2. When specifying multiple maps, the window row/col are the same for
> > > all of them, whereas the map row/col varies with a map's boundaries
> > > and resolution.
> > 
> > I didn't consider multiple maps. :-(  If it's needed, it is not difficult to
> > implement it.
>
> It's probably not that important.
>
> What is important is that -c returns meaningful values, and that the
> significance of those values is documented.
>  
> > > 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(== the device
resolution).

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