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

GRASS GIS GRASS GIS developer
1

this bug's URL: http://intevation.de/rt/webrt?serial_num=816
-------------------------------------------------------------------------

Subject: r.in.bin

Platform: Linux/Intel
Linux distro: RedHat
linux cpu: Intel (i486, i586, pentium ...)
Xwindows version: Xfree 4.0.x
Xwindows manager: KDE 2.x
TclTk version: tcl/tk 8.3
grass binary for platform: I compiled the sources myself
grass sources source: no, I got a source code package from the server, grass5.0.pre2
c compiler name: gcc

Please enter error description here
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.

-------------------------------------------- Managed by Request Tracker

2

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@virgin.net>

3

[CC'd to GRASS5]

Bob Covill wrote:

> 1. Is this actually a problem?

I don't think this is a problem. I wasn't clear on whether the import
failed or the user was confused by the difference in byte sizes.

That was my impression too.

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

That is a good question. Probably could test it with some sample data
for comparison.

There don't seem to be any programs which allow the format to be set.
Searching for G_set_cell_format() indicates that a few import programs
call G_set_cell_format(0) (force 1-byte cells; are these signed or
unsigned?), while the other occurrences force the output to have the
same format as the input.

Of course, if the data is uncompressed, there will be significant
savings.

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

That is a good idea. One issue I can think of is if the user wanted to
convert the data during import. Although I never added the option (there
already seemed to be too many) a mult option would be nice to convert
data during import. For example convert integer centimetres to floating
point metres. Maybe there is no need for this and we could drop the "-f"
flag and make the program set the format internally??

AFAICT, the "-f" flag signifies that the source data consists of
floats. In which case, the flag can't reasonably be removed.

I don't see much point in adding transformation options to r.in.bin.
Most of the desirable operations would apply equally to all of the
r.in.* programs, and the user can just use r.mapcalc to perform the
transformation.

There might be a case for something more specialised than r.mapcalc;
like r.rescale, but which actually rescales the cell values (rather
than the categories), and works on FP maps.

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