[GRASS-user] Problems Running r.flow

[Markus Neteler]

On Fri, Jan 29, 2010 at 3:00 PM, Glynn Clements
<glynn at gclements.plus.com> wrote:
>
> 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.

I have backported the fix applied by Glynn in trunk to 6.5 and 6.4.

Markus