[GRASS-user] Problems Running r.flow

[Glynn Clements]

Hamish wrote:

> > > +    return (fabs(a->ew_res - b->ew_res) < 1e-6 * b->ew_res &&
> > > +        fabs(a->ns_res - b->ns_res) < 1e-6 * b->ns_res);
> > > +}
> 
> Hamish:
> > use GRASS_EPSILON, as it is based on the machine; it
> > doesn't make assumptions about the units you are measuring in.
> ...
> > e.g. for Lat/Long 1e-6 is not enough to accurately
> > represent the
> > region resolution well for sub-meter data. (1e-6*1852*60
> > => ~ 11cm)
> 
> sorry reading again you did say ppm not micron and the code is 1e-6*res,
> not simply 1e-6.
> 
> a plausible finest resolution of 1e-9 for lat/lon (~.1mm) * 1e-6 = 1e-15
> (which is identical GRASS_EPSILON).

That may be too fine; in some cases, values are printed with %.8f.

1e-6 is close enough so long as there are no more than 500,000 rows or
columns, which seems likely to be true in practice.

OTOH, even the most minscule difference in resolution could cause a
duplicate if the grids aren't aligned (the worst case is if they're
offset by exactly half a cell, so the cell centres for one grid align
with the cell corners for the other).

A more precise test would be:

	for (i = 0; i < a->cols; i++)
	    if ((int) floor(G_easting_to_col(G_col_to_easting(i+0.5, a), b)) != i)
	        return 0;

	for (i = 0; i < a->rows; i++)
	    if ((int) floor(G_northing_to_row(G_row_to_northing(i+0.5, a), b)) != i)
	        return 0;

	return 1;

Even this isn't perfectly accurate, as Rast__create_window_mapping()
and compute_window_row() don't use G_easting_to_col() etc, but have
the calculations inlined.

To deal with that, you'd need to read the raster's fcb->col_map (which
is supposed to be private to the raster library) for the column and
use compute_window_row() (which is "static" to lib/raster/get_row.c)
for the column.

It would be simpler to also check that the alignment matches, as well
as the resolution.

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