[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