[GRASS5] r.lzw2z updated...

[Markus Neteler]

On Tue, Jan 23, 2001 at 08:40:53AM -0800, Eric G . Miller wrote:
> On Tue, Jan 23, 2001 at 09:42:47AM +0000, Markus Neteler wrote:
> [snip]
> > Processing pcurv at hude ... Copying ... Done!
> > WARNING: No lzw_compression_bits value in
> >          /home/neteler/grassdata5/hude/hude/cell_misc/tcurv/f_format
> > Skipping raster tcurv at hude -- Not LZW compressed
> > WARNING: No lzw_compression_bits value in
> >          /home/neteler/grassdata5/hude/hude/cell_misc/mcurv/f_format
> > Skipping raster mcurv at hude -- Not LZW compressed
> > WARNING: No lzw_compression_bits value in
> >          /home/neteler/grassdata5/hude/hude/cell_misc/pcurv_rst/f_format
> > Skipping raster pcurv_rst at hude -- Not LZW compressed
> > 
> > The files with WARNING now have a f_format entry like this:
> > more f_format 
> > type: float
> > byte_order: xdr
> > lzw_compression_bits: 0
> > 
> > What does this indicate? Was it an uncompressed file (the map was generated 
> > with s.surf.rst) ? 
> > The map is corrupted now:
> > d.rast tcurv
> > WARNING: error reading compressed map [tcurv] in mapset [hude], row 91
> > 
> > Maybe that's the last bug...
> 
> Try changing the lzw_compression_bits to something like "9" and
> re-running the r.lzw2z script.  Note: r.lzw2z wouldn't have touch the
> f_format file (except to read) if it said it skipped the file.  The
> problem seems to be that somehow s.surf.rst writes an lzw compressed
> file but lzw_compression_bits is not set correctly (should be between 9
> and 20).  Not sure how that would happen.  The reason to have these
> tests of lzw_compression_bits is so the program doesn't even try to read
> non-LZW compressed rasters (which would always fail and cause the
> program to exit).  But, then it has to rely on lzw_compression_bits
> being set to a valid value in order to make the determination (it seems
> to be the only indicator of LZW compression).  The maps are probably not
> corrupted, just LZW compressed with a bogus lzw_compression_bits number.

A good idea! I have changed the f_format and re-run the converter.
r.lzw2z then runs well:

r.lzw2z slope_rst
Processing slope_rst at hude ... Copying ... Done!

and I can even display the map.

The problem with s.surf.rst is that it doesn't use the GRASS functions
to write maps (huh!). Therefore the lzw_compression_bits: 0 occurs.
The module uses "fwrite" as far as I understand
src/sites/s.surf.rst/main.c
Maybe I am wrong and src/libes/rst_gmsl/interp_float/output2d.c is
used with G_put_f_raster_row(). 

Ah yes, see
./interp_float/resout2dmod.c
./interp_float/resout2d.c

    cf1 = G_open_fp_cell_new_uncompressed (params->elev);
    cf1 = G_open_fp_cell_new_uncompressed (params->elev);
Maybe that's the reason?

Could you change the r.lzw2z accordingly so that it can handle these
data as well without WARNING?

Markus

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