Okay,
I've done a small test of new code to use deflate compression for
floating point rasters versus LZW and it seems to work. The reason, of
course, is to get that patented algorithm out of GRASS. I have a
utility that will do the conversion of LZW rasters. It needs a little
cleaning up, but otherwise seems to work correctly. I haven't yet
looked at the g3d stuff, however, I imagine we can just remove the LZW
option alltogether. The docs seem to indicate it is not used by
default, and doesn't buy much after RLE encoding.
So, the big question I need to ask is. are we ready to make this drastic
change to the GRASS source? It's a fundamental change, and will cause
breakage for almost everything, not to mention all users will have to
run the r.lzw2z module on *all* compressed floating point rasters,
before they will be readable again (backups are strongly recommended).
Arguments PRO:
o LZW is patented, and must go unless UNISYS gives us special
dispensation.
o Better to make this change before GRASS 5 goes "stable", since it
will reduce the number of affected users if the change is made later.
o CELL rasters are never LZW compressed (so shouldn't cause problems
for people upgrading from 4.x who haven't used the betas).
o others ???
Arguments CON:
o Will possibly destabilize GRASS code base for a few weeks as kinks are
worked out.
o Burden of "translating" rasters from LZW to Deflate.
o others ???
I think we can wait until after beta9 goes out, this will give me time
to address the g3d stuff as well as clean up the r.lzw2z utility.
Since it is something of an all or nothing situation, I think it's best
to get consensus and when exactly this should be done, and then notify
everyone of this change (so they can act appropriately).
Thanks,
--
Eric G. Miller <egm2@jps.net>
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'