[GRASS-dev] r.proj.seg disk space usage problem

[William Kyngesburye]

On Mar 6, 2007, at 7:18 PM, Hamish wrote:

> William Kyngesburye wrote:
>> I had a chance today to try a VERY large raster with r.proj.seg.
>> 2.7GB raster, 55000x47000 cells.  The memory issue of r.proj have now
>> been moved to a HD space issue.  With 7.75GB free, it chokes at about
>> 75% in the allocating memory stage, while free space slowly drops to
>> zero, with an "Error writing segment file".
>> It seems r.proj.seg, for its segmentation, creates an uncompressed
>> copy of the whole raster on the HD (instead of in memory).  I'm
>> guessing this has something to do with random access speed in  
>> rasters?
>>
>> So I'm back to projecting pieces of the raster, but now so they fit
>> in my disk free space, and patching them together.  Disappointing,
>> but if that's the way it must be, I can live with it.
>
>
> did you pump the memory= option up to a few hundred MB smaller than  
> your
> installed RAM?
>
I didn't try that.  I'm not sure how that would help - that would  
give me 700MB, not a significant portion of the uncompressed raster.   
And it still needs to copy the raster to a temp file.  From Glynn  
back on Feb 12:

> Whereas the original readcell() function simply
> read the map into memory (and thus needed to operate in the alternate
> environment), the new readcell() copies it to a temporary file.
...
> [Aside: my first attempt used a rowio-type strategy, but I discovered
> that you can't switch projections while you have maps open; hence the
> need to copy the map to a temporary file.]


-----
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