[GRASS5] raster inaccuracy

Roger Miller 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.


Roger Miller
 




More information about the grass-dev mailing list