[GRASS5] raster inaccuracy
roger at spinn.net
Fri Nov 12 00:29:13 EST 2004
On Thursday 11 November 2004 20:05, Glynn Clements wrote:
> "g.region rast=..." will trivially force the second case (the
> "integral number" being 1).
That should be true, anyway. When I was putting together those examples I
came across some cases (possibly using a vector file to set the region) where
the bounds of the region did not match the bounds of the file.
> Although it might be useful to have a
> scale= option for g.region to allow rescaling by an integral amount
> ("g.region res=..." suffices when the resolution is an integer, but
> not in general).
There are a number of possible solutions. It seems like the biggest problem
would arise if the display contained more than one raster file with different
boundaries and resolutions.
> Actually, it might also be useful to have rows= and cols= options, so
> that you can set those directly rather than setting res=.
I think we have ewres= and nsres= for that purpose.
> The first case is somewhat more complex, as the monitor's aspect ratio
> won't generally match that of the raster, so you first have to
> determine whether to "pad" the region horizontally or vertically, then
> determine the amount of padding.
I don't think that would be all that difficult. Your d.info code can be used
to produce the monitor dimensions (nx, ny) and the map dimensions are X, Y.
The correct pixel size (region row or column width) should be the larger of
X/nx or Y/ny.
> A third option would be to provide an option to d.rast to
> automatically use the original raster's resolution, so that it is only
> resampled once (in general, it gets resampled from the original grid
> to the current region, and then again to the monitor's pixel grid).
> However, this is risky, because what you're seeing isn't what r.* will
> get. It's probably better to force the user to explicitly set the
> region so that the display matches the "view" that r.* will receive.
As conditions are now the problem can only be solved with user education,
which is probably the hardest solution of all. It is probably better in the
long run to build some kind of solution in the code.
For my part I do a lot of my work these days through a custom front end that I
wrote mostly to simplify some of the display and query procedures. I think
that for now at least I will try setting it up to keep the region row and
column dimensions equal to the pixel size. The region will have to be
manually reset before using r.mapcalc, r.stats, and so on, but that is
normally true even without making any further changes.
More information about the grass-dev