[GRASS5] bug in d.what.rast

[GRASS]

-c bug fixed.

> From grass5-admin at grass.itc.it Mon Mar  4 01:17:37 2002
> From: Glynn Clements <glynn.clements at virgin.net>
> To: grass5 at grass.itc.it
> Subject: Re: [GRASS5] bug in d.what.rast
> Date: Sun, 3 Mar 2002 15:48:06 +0000
>
>
> Eric G. Miller wrote:
>
> > > 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=".

> > >
> > > 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.
> >
> > 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).
>
> The category reported is for the cell which is displayed beneath the
> mouse cursor. But that cell can be addressed using either map row/col
> or window row/col.
>
> The main reasons that I can see for using window row/col are:
>
> 1. Those correspond to r.mapcalc's row() and col() functions, and I
> can't immediately think of anywhere else that rows/cols are visible to
> the user. However, r.mapcalc's row() and col() functions use one-based
> indices, while "d.what.rast -c" uses zero-based indices.

-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.

>
> 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.

>
> 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.

>
> --
> Glynn Clements <glynn.clements at virgin.net>
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
>