[GRASS-dev] [GRASS GIS] #2750: LZ4 when writing raster rows; better than double I/O bound r.mapcalc speed
GRASS GIS
trac at osgeo.org
Mon Dec 28 08:44:26 PST 2015
#2750: LZ4 when writing raster rows; better than double I/O bound r.mapcalc speed
--------------------------+---------------------------
Reporter: sprice | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.1.0
Component: Raster | Version: svn-trunk
Resolution: | Keywords: ZLIB LZ4 ZSTD
CPU: OSX/Intel | Platform: MacOSX
--------------------------+---------------------------
Comment (by neteler):
'''To summarize the current state'''
We currently have the following compression methods in trunk (according to
lib/gis/compress.c; set by `export GRASS_COMPRESSOR=XXX`):
* `NONE` (uncompressed)
* `RLE` (generic Run-Length Encoding of single bytes)
* `ZLIB` (DEFLATE, good speed and compression)
* with zlib compression levels (`export GRASS_ZLIB_LEVEL=X`): -1..9 (-1
is default which is level 6)
* Notes from #comment:23: ZLIB level = 0 tells ZLIB to copy the data as
is from source to destination. With CELL maps, the rasterlib will then
still trim high zero bytes with trim_bytes() which can already reduce the
data size considerably, but ZLIB will not compress the data.
* `LZ4` (fastest, low compression)
* `BZIP2` (slowest, high compression)
NULL file compression: At time it must be explicitly turned on (IMHO it
should become the default) with
* `export GRASS_COMPRESS_NULLS=1`
Backward NULL file compression compatibility could be implemented in
relbranch70 only by ZLIB's DEFLATE (see #comment:36). Hence ZLIB may
qualify for the default NULL compression algorithm.
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2750#comment:40>
GRASS GIS <https://grass.osgeo.org>
More information about the grass-dev
mailing list