[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
Thu Nov 12 01:44:41 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 glynn):
Replying to [comment:23 mmetz]:
> As before, the rasterlib makes only partial use of the generic
compression methods: no compression and RLE is handled by the rasterlib
internally, and RLE is not supported for fp maps. Creating uncompressed
raster maps has been and should be only possible with
`Rast_open_new_uncompressed()`.
There's no fundamental reason why RLE can't be supported for FP maps; it's
just seldom useful. RLE is most useful for category data where you have
contiguous areas with the same value, and such maps tend to be integer
maps (e.g. you can't create a reclass of a FP map).
No compression used to be a special case because it means that maps don't
have to be written sequentially: 6.x has G_put_map_row_random() which
allows data to be written to an arbitrary row rather than to the "next"
row. 7.x doesn't have an equivalent because nothing actually used it.
In theory, even compressed maps can be written non-sequentially: just
append the data to the end of the file then update the row pointer for the
row. However, overwriting a row will result in the old data taking up
space in the file.
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2750#comment:29>
GRASS GIS <https://grass.osgeo.org>
More information about the grass-dev
mailing list