[GRASS5] rlzw-ssurfrst

GRASS GIS GRASS GIS developer
1

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().

yes, all output raster maps from s.surf.rst are
written in src/libes/rst_gmsl/interp_float/output2d.c by 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?

resout.c is not used by s.surf.rst but it is for r.resamp.rst
(see IL_resample_output_2d)

see DESCRIPTION.INTERP what each function does.

The problem may be that s.surf.rst was ported to FP before
FP was stable so it may contain some relics from older versions
of FP implementation. Although I don't understand why elevation is
OK and slope and curvatures are not, because they are written the same way,
(at least as far as I can tell).

Helena

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

2

On Tue, Jan 23, 2001 at 11:57:04AM -0600, Helena Mitasova - staff 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().

yes, all output raster maps from s.surf.rst are
written in src/libes/rst_gmsl/interp_float/output2d.c by G_put_f_raster_row()

Very good.

>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?

resout.c is not used by s.surf.rst but it is for r.resamp.rst
(see IL_resample_output_2d)

see DESCRIPTION.INTERP what each function does.

The problem may be that s.surf.rst was ported to FP before
FP was stable so it may contain some relics from older versions
of FP implementation. Although I don't understand why elevation is
OK and slope and curvatures are not, because they are written the same way,
(at least as far as I can tell).

My data I a currently (failing to) convert(ing) are from 1999.
Perhaps I converted them with s.surf.rst not stable (you remember me
testing your module once).

So, testing the current s.surf.rst....
.. Yes, the maps generated now are o.k. (of course).

Conclusion: Somewhere in the world maps may exist which are generated
from s.surf.rst without being properly compressed.
Eric, I feel that this cannot be done with r.lzw2z (right). But maybe
I am the only person in the world having such data. And I know how
to fix this manually.

I cannot tell if
lzw_compression_bits: 0
is allowed or not. If not, this may only occur in above circumstances
(results from older beta5 code), and r.lzw2z could handle it. If yes,
r.lzw2z can't handle it and we just ignore this problem (telling those
people how to fix it manually by changing the f_format entry).

Markus

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