[GRASS-dev] [GRASS GIS] #2349: CELL raster format: make ZLIB level 3 standard compression instead of RLE

[GRASS GIS]

#2349: CELL raster format: make ZLIB level 3 standard compression instead of RLE
-------------------------+--------------------------------------------------
 Reporter:  neteler      |       Owner:  grass-dev@…              
     Type:  enhancement  |      Status:  new                      
 Priority:  critical     |   Milestone:  7.0.0                    
Component:  Raster       |     Version:  svn-releasebranch70      
 Keywords:               |    Platform:  All                      
      Cpu:  Unspecified  |  
-------------------------+--------------------------------------------------

Comment(by neteler):

 Replying to [comment:2 glynn]:
 > Replying to [ticket:2349 neteler]:
 > > At time, integer maps (CELL) are still compressed with RLE
 > > This leads to a huge waste of disk space when it comes to large
 > > data.
 > >
 > > Proposal: make ZLIB, level 3 the standard compression.
 >
 > Is GRASS_INT_ZLIB support now old enough that it can be taken for
 granted?

 I hope yes. I am not aware of negative reports.

 > > At time we can enable the environment variable GRASS_INT_ZLIB
 > > but it will use the default ZLIB level 6 compression which
 > > is too CPU intensive. So a  (user) control over this is important.
 >
 > The current behaviour is that setting GRASS_INT_ZLIB to anything (even
 an empty string) will enable zlib compression at the hard-coded level.

 Exactly.

 > One option is to parse the value as an integer and use the result as the
 compression level. However, it's possible that people are currently using
 e.g. GRASS_INT_ZLIB=1 to enable it with the existing default level.
 >
 > Another option is to add another environment variable for the level.

 Yes, a new GRASS_ZLIBLEVEL may be less invasive.

 > Aside: if there are still systems out there using the historical limit
 of 4096 bytes of memory for the combination of environment variables and
 arguments (argv), we might want to think about making GRASS less greedy
 with respect to environment variables.

 You mean the number and/or the length?

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/2349#comment:3>
GRASS GIS <http://grass.osgeo.org>