[GRASS5] [bug #816] (grass) r.in.bin

[Glynn Clements]

Request Tracker wrote:

> Subject: r.in.bin

> When importing binary raster file with r.in.bin, the option "number
> of bytes/cell" is not taken into account.
> 
> I tried to import lat./long. AVHRR ancillary files.
> The projection is Goode Homolosine.
> The data are 2 bytes, according the NOAA documentation 
> (cf. http://daac.gsfc.nasa.gov/CAMPAIGN_DOCS/FTP_SITE/readmes/pal.html)
> ________________________________________________________________________ 
>  Parm.         bits               Offset        Gain        Bin. min/max
> ___________________________________________________________________  
>   lat          16-bit unsigned       9010        .01         10 / 18010
>   lon          16-bit unsigned      18010        .01         10 / 36010  _______________________________________________________________________
> 
> Consequently, I used the following commands :
> 
> r.in.bin  input=avhrrpf.lat.1nnfaf output=avhrrpf.lat.1nnfaf bytes=2 north=38.5 south=-37.8 east=61.3 west=-20 r=1060 c=1100 
> r.in.bin  input=avhrrpf.lon.1nnfaf output=avhrrpf.lon.1nnfaf bytes=2 north=38.5 south=-37.8 east=61.3 west=-20 r=1060 c=1100 
> 
> But the r.support command gave me 4 bytes/cell.
> 
> For getting the correct raster layer, I had to copy the binary files in cell
>  directory, to edit the cellhd file, and to run the r.support command.

1. Is this actually a problem?

2. Is there likely to be any significant space reduction from using
1-byte or 2-byte cells, or will the compression mean that there's no
significant difference?

3. Should r.in.bin set the internal format according to the original
format?

AFAICT, the two formats can only match when importing signed data
without null values. If the data is unsigned, or contains nulls,
presumably the next size up would have to be used (unless the input
data is first scanned to determine its range; is this worthwhile?)

-- 
Glynn Clements <glynn.clements at virgin.net>