[GRASS-dev] Re: [GRASS-user] problems using r.proj with large data set

[William Kyngesburye]

I just had a reason to try this out (nearly forgot about it).  I'm a  
little confused - you say here that the cache size is fixed, yet  
there is an option to set the cache size (in MB) mentioned in the  
docs.  Maybe this was added later?

The docs should probably also be updated with info relevant to  
r.proj.seg, instead of being a straight copy of the r.proj description.

On to trying to run it - tempfile problems (I recall seeing something  
about tempfiles on the list).

In location saproj, mapset srtm.  Projecting data from location world  
(LL proj), mapset sa, map sa (7.5GB):

 > r.proj.seg loc=world map=sa in=sa out=srtm

Input Projection Parameters: blah blah
Output Projection Parameters: blah blah
Input: blah blah
Output: blah blah

ERROR: can't make mapset element .tmp/Sumomo.local
        (/Volumes/Guu/gis/grassdb/world/srtm/.tmp)

[it doesn't get to the "Allocating memory and reading input map..."  
message]

... how the heck is it getting world/srtm as the current mapset (for  
creating temp files in)!?  It should be saproj/srtm.  Somehow the  
location is getting mixed up.

 > g.gisenv get=MAPSET
srtm
 > g.gisenv get=LOCATION_NAME
saproj

return the correct values.

On Dec 17, 2006, at 7:14 PM, Glynn Clements wrote:

> I've added to CVS a modified version of r.proj named r.proj.seg. This
> behaves identically to r.proj, but uses a tile cache rather than
> reading the entire map into memory.
>
> Currently, each tile is 64 * 64 cells, and the size of the cache is
> fixed at 2 * (nx + ny) tiles (where nx * ny is the size of the source
> region in tiles), which I would expect to suffice for any realistic
> transformation.
>
> [It will definitely suffice for any affine or "near"-affine
> transformation. It would be useful to know what level of distortion
> needs to be accommodated in practice.]
>
> Cache replacement is random (i.e. when a new tile is loaded, the tile
> which it replaces is selected at random). In practice, random
> replacement tends to work almost as well as an "optimal" algorithm,
> but without the overhead of maintaining usage statistics, as well as
> not having any degenerate cases.
>
> Suggestions for improvements and/or performance statistics for
> "real-world" usage are welcome.
>

-----
William Kyngesburye <kyngchaos at kyngchaos.com>
http://www.kyngchaos.com/

"Oh, look, I seem to have fallen down a deep, dark hole.  Now what  
does that remind me of?  Ah, yes - life."

- Marvin