[GRASS5] [bug #3742] (grass) r.out.bin output incorrect compared with r.out.netcdf

[Hamish]

> this bug's URL: http://intevation.de/rt/webrt?serial_num=3742
> ---------------------------------------------------------------------
> 
> Subject: r.out.bin output incorrect compared with r.out.netcdf
> 
> Platform: GNU/Linux/i386
> grass binary for platform: Compiled from Sources
> GRASS Version: 6.0.1
> 
> r.out.bin fails with the -h option on DCELL maps. 

"fails" how? Segmentation Fault? Runs ok, but output not as expected?
Try byte swapping the output of r.out.bin and try again (-s)?


> see http://thread.gmane.org/gmane.comp.gis.grass.user/7618
> > []% r.out.bin -h null=NaN in=srtm out=srtm.grd

note null=NaN should not work [yet it does! G_parser bug!]. As written
r.out.bin will only take an integer for the null value at the command
line. I don't know if this should be allowed to be something of another
type. A char string seems wrong for a binary file, I don't know if floats 
and double are ok or if the cast to int for CELL maps would be "wrong" 
in that case. Allowing float or double for that would be the only way to
get "nan" accepted for null= as it doesn't exist for integers (yet 
G_parser() allows any string for parm->type = TYPE_INTEGER; ??).
Test added to r.out.bin disallow this in future.


my best guess at the bug is this:
[note null_str is defined as an int, not a string]

    /* Set up Parameters for GMT header */
    if (flag.gmt_hd->answer) {
...
	if (flag.swap->answer)
	    TIFFSwabLong((uint32 *) & null_str);
	sprintf(buf, "%d", null_str);
...
    }

then below

	    if (!G_is_null_value(ptr, out_type)) {
... }
	    else {
...
		if (out_type == DCELL_TYPE) {
		    null_val_d = (double)null_str;
		    if (flag.swap->answer)
			TIFFSwabDouble((double *)&null_val_d);
		    fwrite(&null_val_d, sizeof(double), 1, fp);
		}
... }


the GMT -h flag swaps the endianness of null_str and then later the 
binary writer swaps the swaped version? The fix would be to swap a temp 
variable not the main one when writing the .hdr file, the same way the
main binary writing code does. (is swapping it in the header.remark 
string even appropriate??)


> Looking at the debian source code 6.0.1 it appears that someone
> commented out lines of code in r.out.bin module that included an {, a
> simple checkout shows that there is an unbalanced } at the end of the
> file.
> 
> See, line 121 of SRC/raster/r.out.bin/main.c

I don't think that's it. For one thing it won't compile with an 
unbalanced {}. I think that code is trying to allow you to take the
output filename from the map name if output= is not given. *char vs
char[123] is why that fails.

I have cleaned up the code a bit in CVS so it is easier to read and 
fixed a BIL hdr file nodata bug.

I don't use GMT or ArcView day-to-day so can't really test.



Hamish