On Fri, Jan 29, 2010 at 3:00 PM, Glynn Clements <[email protected]> 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 _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
