[GRASS5] bug in d.what.rast

[GRASS5]

-c bug fixed.

From grass5-admin@grass.itc.it Mon Mar 4 01:17:37 2002
From: Glynn Clements <glynn.clements@virgin.net>
To: grass5@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@virgin.net>
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

[Glynn_Clements]

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.

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

[GRASS5]

From glynn.clements@virgin.net Mon Mar 4 11:37:08 2002
From: Glynn Clements <glynn.clements@virgin.net>
Date: Mon, 4 Mar 2002 02:12:34 +0000
To: GRASS <grass@geni.cemtlo.com>
Cc: grass5@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@virgin.net>

[Roger_Miller]

On Sunday 03 March 2002 20:09, GRASS wrote:

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.

r.what doesn't take input from the mouse.

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

Does the resolution reported by G_get_window ever differ from the resolution
in a displayed raster (assuming only one raster is being displayed)?

Roger Miller

[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@virgin.net>