Re: zlib compression for CELL maps

At least for SRTM rasters, it depends on whether there are negative  
elevations (common around coastal areas).  I noticed this a while  
back and wondered about it.  I don't remember the details, but it  
came down to what order of integer is needed - 1, 2 or 4 bytes,  
unsigned - to represent all the values in the region.  BUT, if there  
were negative integers it always used a signed 8 byte integer (or  
something large like that).  Compression came into it also I think,  
again I don't remember details.

So SRTM tiles in coastal areas are often much bigger than you'd  
expect, though with the new version 2 SRTM that shouldn't be as big a  
problem since water areas have been filled with a flat 0 elevation,  
or an appropriate elevation for lakes.

I don't know about the GRASS_INT_ZLIB variable (env? compile?), but I  
was under the impression that I couldn't do anything about it.

On Jan 4, 2006, at 8:44 AM, Jaro Hofierka wrote:

> Hello,
>
> I have a problem with a size of integer (CELL) maps. It is strange  
> that the size of compressed integer maps is bigger than the same  
> maps in floats. Recently, we tried to import srtm files and  
> floating point maps took much less disk space then integers 
> I tried to use the GRASS_INT_ZLIB variable, but the compression  
> flag in a header file is still set to 1 (should be 2?). Problably I  
> missed something. I re-compiled GRASS using zlib.
> Many thanks for any hints!
>
> Jaro
>

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