bug in r.in.sunrast?

Sorry folks - me again.

I just successfully imported a whole swag of rasters using r.in.sunrast,
*except* for one, which has an odd # columns. the raster is now "sheared" -

Reading Sun's rasterfile definition, it requires that lines are padded out
to an even # of bytes. It looks like grass has taken that extra byte and
has used it as part of the data instead of discarding it. Has anyone else
found this problem?

I am using grass4.0 still.

I can get around it as I wrote the rasterfile generator myself, but I could use
any other alternatives. (I can also, with a bit more effort, get the same
program to rotate my images (see last posting) but would rather not.)

bye

Simon Cox
----
__________________________________________________________________
        Dr Simon Cox
         __ L
      ,~' L_|\ Department of Earth Sciences
   ,-' \ Monash University
   ( \ Clayton Vic 3168 Australia
   \ ___ /
    L,~' "\_x/ Phone +61 3 565 5762
              u Fax +61 3 565 5062
        simon@cerberus.earth.monash.edu.au
__________________________________________________________________

I ran into the same problem last week. I temporarily solved the problem by
modifying the source-code of r.in.sunrast, in a sence that it only
works with an odd number of bytes in one row. When I have an even number,
I will have to modify the code again. Maybe in grass4.1 the bug is solved.

Ronald Wiemer
Archis centre of expertise
Amersfoort
The Netherlands