[GRASSLIST:6438] Re: Weird behavior (GDAL???)

Jonathan Greenberg jgreenberg at arc.nasa.gov
Tue Apr 12 22:42:31 EDT 2005

I actually got the problem reduced a bit more -- turns out the export WAS
working properly, but either GRASS was putting some error in the header or
ENVI (which I was importing the data into) was reading the grass exported
header incorrectly.  ENVI was thinking it was a long integer, but when I
simply "fixed" the header to read "floating point" voila, the image was


On 4/12/05 7:35 PM, "Hamish" <hamish_nospam at yahoo.com> wrote:

>> So I exported some rasters using r.out.bin and, under grass 5.7 (macos
>> x fink install) the outputs were fine, but with grass 6.0 + gdal 1.2.6
>> I'm now getting outputs which, while visually ok, are coming out as
>> gargantuan numbers instead of smaller decimals...  Thoughts?
> Sounds very much like a big/little endian problem..
> try using the '-s' flag with r.out.bin.
> There is some C code for translating in raster/r.out.bin/tif_swab.c
> if you want to try and convert manually.
> or if you have access to Matlab, you can just do
> fp1= fopen('file.bin','r','ieee-be');
> where 'ieee-be' can be:
> ieee-be     for big endian
> ieee-le     for little endian
> ieee-be.l64 for big-endian 64-bit long data type
> ieee-le.l64 for little endian 64-bit long data type
>  (+ more options in the fopen help page)
> try playing around with the different types until you find the correct
> one; it should be one of the above.
> If it ends up being GRASS not exporting correctly, please let us know.
> Should we issue a "Exporting in big-endian format" message?
> Hamish

Jonathan A. Greenberg, PhD
NRC Research Associate
NASA Ames Research Center
MS 242-4
Moffett Field, CA 94035-1000
AIM: jgrn307
MSN: jgrn307 at hotmail.com

More information about the grass-user mailing list