[GRASS5] raster inaccuracy

[Roger Miller]

Glynn, thanks for looking into this for me.

On Thu, 11 Nov 2004 18:15:28 +0000, Glynn Clements wrote

> The key point is that, in common with almost every other program 
> which operates upon rasters, d.rast isn't reading (or displaying)
>  the original raster, but the raster after it has been resampled according
> to the current region settings.
> 
> If the current region has the same resolution as the raster, but 
> isn't aligned to the same grid, the result is that the raster which 
> is displayed on the monitor will be shifted by up to +/- half a cell.

I see what you mean.  It leaves me with a problem.  In the general case grass
raster displays and grass raster queries are not accurate; they may be grossly
inaccurate.  That is because the original data when displayed are resampled to
a grid that may have little in common with the original data array.  In my
examples the data were displayed in a grid that overlapped as little as 25% of
the actual data cell.  The d.what.rast query returns the data *as displayed*
not the original data, so it propogates the problem.

It appears to me that there are two (and only two) cases in which the raster
display and the raster queries will always be accurate:

1) The region resolution is set to the pixel size for the current display. 
For instance, in my 2x2 example with the default 640x480 monitor size that
means setting the row and column sizes to 22 units.

2) The region boundaries are set to correspond exactly to boundaries between
rows and columns in the original data and the region resolution is set so
there is an integral number of region rows and columns for each row and column
in the original data.

I don't understand what gets displayed (hence queried) in the case where the
data cells are smaller than the pixel size.  That seems to be a largely
different problem, but another problem with accuracy.

The first solution is easy.  The simple solution is generally useful for the
purpose of display and query but it would not work for most analyses of raster
data -- through r.mapcalc, for instance.

The second case is more complicated, but I think it would work for all cases
where the pixel size is much smaller than the resolution of the data.

It is at least a burden on users to require them to make sure those conditions
are met, and probably really too much to expect from most users.  Certainly I
don't like the prospect of manually checking and adjusting the region every
time I need to query a raster map.

Is there some way to impose those limits on the region definitions in an
automatic fashion?

> This isn't an issue for vectors, as they aren't aligned to a grid.
> 
> If there's a flaw here, it's that d.pan appears to be aligning the
> region to a half-cell grid. I have no idea why it does this, but it
> probably shouldn't be performing any alignment. IOW, after panning,
> the vector and the raster should be misaligned by an arbitrary amount
> (in the range +/- half a cell), rather than by either half a cell or
> nothing.

d.pan's behavior might be a problem, but it is a different problem.  It did
have the advantage of maximizing the error in my examples.  The same (but less
extreme) problem arises with the region is manually adjusted by changing the
region boundaries and/or resolution.

Roger Miller