[GRASS5] LZW unhooked in libgis and libg3d now.

[Eric G . Miller]

On Sun, Dec 17, 2000 at 04:41:55PM +0000, Markus Neteler wrote:
> Yes, I should add an announcement. What about the r.lzw2flate tool?
> I tried with success, maybe it should go for some time into the
> GRASS code? Will it read LZW even if the GRASS is already compiled with
> FLATE compression? In this case it would be nice to have an auto-detection
> which automatically runs r.lzw2flate if an LZW compressed raster file
> is found (would be most user convenient). I am sure there is no problem
> to have LZW in this small module as the intention is to get rid of LZW.

Well, the tool is in the same spot.  I don't think it should be part of
any base install because it really is only useful once.  If a user tries
to use it subsequently, it'll just bail out with some errors.

It is stand alone (with respect to low-level compression in libgis),
since it reads the raster file directly, decompresses it from LZW and
then compresses it with DEFLATE to a temp file.  Then it runs a little
sanity test to make sure it can read the newly compressed temp file.  If
that goes okay, the new temp file is written over the old compressed
version.  Unfortunately, it's not too smart about the type of
compression.  There's the header flag which it uses to determine if a
file is compressed (by some means), but it won't know if it's LZW or
DEFLATE until it tries to read/decompress as LZW (which will fail if
it's not LZW compressed).  The program will just spit out an error and
quit if it encounters a non-LZW compressed file that passed all the
other checks (compressed=1, fp=true, mapset=G_mapset(), reclass=false).

> I fear we'll get tons of emails of people having problems to migrate their
> location to the new compression method if this isn't done by GRASS itself.

I understand what your saying, I'm just not sure how to do it.  The
r.lzw2z program can operate on an entire mapset which is about as close
as I can think of for automation without having transition code in the
library itself (which implies retaining the lzw.c code).  I just
hesistate to include it in the sources directly in order to keep that
algorithm out of the main distribution and for the reason above.

Since this only affects GRASS 5.0beta users, I'll rationalize that it's
okay to have breakage since these users were using a "test" version
of the code.  Certainly, an addition to the GRASS FAQ, and probably
other places, is in order.  The word will get out.

-- 
Eric G. Miller <egm2 at jps.net>

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'