Hi Glynn, I have created a ticket for this issue: http://trac.osgeo.org/grass/ticket/1752
So we can discuss this using the trac ticket system. Best regards Soeren 2012/10/1 Glynn Clements <[email protected]>: > > Sören Gebbert wrote: > >> > The ideal solution would be to store runs of >= 254^2 as multiple >> > runs. That would maintain backward compatibility while avoiding the >> > bug. But that would require re-writing Rast3d_rle_encode() and >> > Rast3d_rle_count_only(); there's no way that G_rle_codeLength and >> > rle_length2code can be fixed, as they assume that any length can be >> > encoded. >> >> So this bug is not fixable at all? > > The bug is fixable, but the fix isn't trivial. > >> >> However, i do not understand the advantage of having RLE first and a >> >> LZ77 or LZ78 compression afterwards. >> >> Shouldn't be the LZ77/78 compression sufficient for compression of >> >> float/double values? >> > >> > For sparse data, using RLE first can often provide a noticeable >> > improvement. >> >> I would prefer to disable RLE and keep the code only for backward >> compatibility. > > That's certainly simpler, but you should first check how much > difference it makes to a sparse (e.g. all-zeros) map. > > -- > Glynn Clements <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
