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

[Glynn Clements]

[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 at virgin.net>