[GRASS-user] Problems Running r.flow

[Glynn Clements]

Rich Shepard wrote:

> > Did you try "g.region rast=aber5m" without the other options?
> 
> Glynn,
> 
>    Not until just now. It's busy calculating maps now.
> 
>    Why does not specifying res or '-ap' make such a difference? Perhaps I can
> solve future situations like this myself if I better understand what's going
> on under the hood.

The region definition consists of 8 values: north, south, east, west,
ns_res, ew_res, rows, and cols. But two of these are redundant due to
the constraints:

	ns_res = (north - south) / rows
	ew_res = (east - west) / cols

So there are actually only 6 independent values. For each equation,
you can choose any 3 values and the fourth is uniquely determined by
those 3.

Furthermore, rows and cols must be integers. Consequently, ns_res and
ew_res can only be equal to north - south or east - west divided by
some integer.

Almost any operation upon a "struct Cell_head" (e.g. reading a map's
cellhd, reading the WIND file, specifying a specific reagion, etc)
recalculates the ns_res and ew_res fields from the other 6 values as
above.

With g.region, if you use the -a switch and/or the align= option, the
bounds will be adjusted so that the height/width is equal to the
resolution multiplied by the number of rows/columns.

Regardless of which options are used, the final step will recalculate
the resolution as above. If you used the -a switch or the align=
option, this final recalculation should have no effect, although in
practice it may adjust the resolution by a miniscule amount.

[Essentially, while (a/b)*b should be equal to a, rounding errors
introduced in the result a/b may cause it to differ very slightly.]

-- 
Glynn Clements <glynn at gclements.plus.com>