1. Hopefully fix a NULL file problem Markus reported, now never uses the
G_open_cell* functions (which I think was where the problem was??).
2. Build in intelligence about FP rasters that have already been
converted. Both script and libraries now set lzw_compression_bits in
cell_misc/<name>/f_format to '-1'. This value makes no sense for LZW
and is unused by libz.
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Sun, Jan 21, 2001 at 07:25:11PM -0800, Eric G . Miller wrote:
I've update the r.lzw2z conversion module.
1. Hopefully fix a NULL file problem Markus reported, now never uses the
G_open_cell* functions (which I think was where the problem was??).
2. Build in intelligence about FP rasters that have already been
converted. Both script and libraries now set lzw_compression_bits in
cell_misc/<name>/f_format to '-1'. This value makes no sense for LZW
and is unused by libz.
Eric,
just tested the updated module:
- no segfault any more, but
- I get this warning:
Processing aspect@helge ... Copying ... WARNING:
cell_misc/aspect/f_format file may be corrupted!
Processing slope@helge ... Copying ... WARNING: cell_misc/slope/f_format
file may be corrupted!
There seems to be one bug left.
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Prior to conversion, lzw_compression_bits should be between 9 and 20.
If it failed to update/write the file, the warning is correct. However,
we don't want it to fail
--
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'
On Mon, Jan 22, 2001 at 02:35:34AM -0800, Eric G . Miller wrote:
On Mon, Jan 22, 2001 at 09:36:25AM +0000, Markus Neteler wrote:
> Eric,
>
> just tested the updated module:
>
> - no segfault any more, but
> - I get this warning:
> Processing aspect@helge ... Copying ... WARNING:
> cell_misc/aspect/f_format file may be corrupted!
>
> Processing slope@helge ... Copying ... WARNING: cell_misc/slope/f_format
> file may be corrupted!
>
> There seems to be one bug left.
Could you check what one of these files looks like? Maybe I need to
handle a return value differently... Following conversion it should
look like...
If it failed to update/write the file, the warning is correct. However,
we don't want it to fail
Yes, but what could be wrong?
Maybe it is o.k., just the warning is wrong.
Note: I didn't test the map (should have done). As I just
trashed my GRASs for recompilation, I cannot test this minute.
Update mail should follow in 10 minutes...
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Mon, Jan 22, 2001 at 09:36:25AM +0000, Markus Neteler wrote:
On Sun, Jan 21, 2001 at 07:25:11PM -0800, Eric G . Miller wrote:
> I've update the r.lzw2z conversion module.
>
> 1. Hopefully fix a NULL file problem Markus reported, now never uses the
> G_open_cell* functions (which I think was where the problem was??).
>
> 2. Build in intelligence about FP rasters that have already been
> converted. Both script and libraries now set lzw_compression_bits in
> cell_misc/<name>/f_format to '-1'. This value makes no sense for LZW
> and is unused by libz.
Eric,
just tested the updated module:
- no segfault any more, but
- I get this warning:
Processing aspect@helge ... Copying ... WARNING:
cell_misc/aspect/f_format file may be corrupted!
Processing slope@helge ... Copying ... WARNING: cell_misc/slope/f_format
file may be corrupted!
There seems to be one bug left.
I have tried the converted maps: They are OK! So maybe just
the return value is reverted (it simply shouldn't print above warning).
Can't see any problems except the confusing warning with your updated
r.lzw2z
Re-running it is o.k. as well:
Skipping raster aspect@demomapset -- Not LZW compressed
Skipping raster slope@demomapset -- Not LZW compressed
So, if you revert the if-clause (or whatever) for the WARNING,
I think r.lzw2z is working well.
Continuing to convert 1000s of maps...
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Mon, Jan 22, 2001 at 06:01:03PM +0000, Markus Neteler wrote:
> Eric,
>
> just tested the updated module:
>
> - no segfault any more, but
> - I get this warning:
> Processing aspect@helge ... Copying ... WARNING:
> cell_misc/aspect/f_format file may be corrupted!
>
> Processing slope@helge ... Copying ... WARNING: cell_misc/slope/f_format
> file may be corrupted!
>
> There seems to be one bug left.
I have tried the converted maps: They are OK! So maybe just
the return value is reverted (it simply shouldn't print above warning).
Can't see any problems except the confusing warning with your updated
r.lzw2z
Re-running it is o.k. as well:
Skipping raster aspect@demomapset -- Not LZW compressed
Skipping raster slope@demomapset -- Not LZW compressed
So, if you revert the if-clause (or whatever) for the WARNING,
I think r.lzw2z is working well.
Okay, r.lzw2z is slightly updated. Should fix the small error when only
one raster exists in fcell/ (wasn't dangerous). Tried to fix warning
message above. Can't really figure it out. If I add a print statement,
to print the "stat" value returned by the G_fwrite_key_value() function,
the error goes away. Go figure...
All I can reason is that the calling function G_write_key_value_file()
checks the return value of fclose() against EOF and reports an error
code if EOF was returned. Maybe a glibc bug? I haven't really tested
that possibility. Anyway, it always seems to work correctly whether or
not the return code is correct. I did check the G_fwrite_key_value() is
returning zero. Hmm...
--
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'
On Mon, Jan 22, 2001 at 09:20:39PM -0800, Eric G . Miller wrote:
On Mon, Jan 22, 2001 at 06:01:03PM +0000, Markus Neteler wrote:
just tried your updated version.
A sample session is looking like this:
Doing translations ...
Processing dgm12_5@hude ... Copying ... Done!
Processing asp@hude ... Copying ... Done!
Processing dgm5_rst@hude ... Copying ... Done!
WARNING: No lzw_compression_bits value in
/home/neteler/grassdata5/hude/hude/cell_misc/slope_rst/f_format
Skipping raster slope_rst@hude -- Not LZW compressed
Processing aspect_rst@hude ... Copying ... Done!
Processing pcurv@hude ... Copying ... Done!
WARNING: No lzw_compression_bits value in
/home/neteler/grassdata5/hude/hude/cell_misc/tcurv/f_format
Skipping raster tcurv@hude -- Not LZW compressed
WARNING: No lzw_compression_bits value in
/home/neteler/grassdata5/hude/hude/cell_misc/mcurv/f_format
Skipping raster mcurv@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@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...
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Tue, Jan 23, 2001 at 09:42:47AM +0000, Markus Neteler wrote:
[snip]
Processing pcurv@hude ... Copying ... Done!
WARNING: No lzw_compression_bits value in
/home/neteler/grassdata5/hude/hude/cell_misc/tcurv/f_format
Skipping raster tcurv@hude -- Not LZW compressed
WARNING: No lzw_compression_bits value in
/home/neteler/grassdata5/hude/hude/cell_misc/mcurv/f_format
Skipping raster mcurv@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@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.
--
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'
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@hude ... Copying ... Done!
> WARNING: No lzw_compression_bits value in
> /home/neteler/grassdata5/hude/hude/cell_misc/tcurv/f_format
> Skipping raster tcurv@hude -- Not LZW compressed
> WARNING: No lzw_compression_bits value in
> /home/neteler/grassdata5/hude/hude/cell_misc/mcurv/f_format
> Skipping raster mcurv@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@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:
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
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@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Tue, Jan 23, 2001 at 06:10:57PM +0000, Markus Neteler wrote:
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
Could you change the r.lzw2z accordingly so that it can handle these
data as well without WARNING?
I will update to compare against the -1 token instead of checking the
9-20 range. This ought to solve the problem for most cases...
--
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'
