[GRASS5] [bug #2061] (grass) r.los needs FP update

[Glynn Clements]

Markus Neteler wrote:

> > > Sounds good - but the segment library (src/libes/segment/) seems
> > > to be limited to CELL.
> > 
> > That contradicts the documentation, which implies that the cells may
> > have arbitrary size; i.e. a cell is just "len" bytes, where "len" is
> > given in the call to segment_format(). Cursory examination of the code
> > supports the documentation.
> 
> OK - I tried to update the code and ended up with
> WARNING: can't put float row into integer map

That's a libgis issue; you have to create the output map as FP (with
G_open_fp_cell_new(), G_open_raster_new(..., FCELL_TYPE) etc) if you
want to put FP rows.

If you want to write a CELL map, just open the input map as CELL and
use CELL internally. G_get_raster_row() etc will coerce FCELL and
DCELL to CELL (via quantisation rules), but G_put_raster_row() etc
refuse to coerce FCELL or DCELL to CELL (but will do the other
combinations).

It wouldn't be difficult to make libgis do those coercions, so
presumably they were omitted deliberately. Probably due to the
possibility of overflow.

> that's why I assumed (after a *quick* grep for CELL in segment)
> that's related to segment.

No; the segment library doesn't know anything about GRASS data types
(and doesn't use any GRASS functions except G_malloc and G_warning). 
The only occurrences of CELL in the segment code are in comments:

get_row.c:11:/*  int segment_get_row (SEGMENT *SEG, CELL *buf,int row) */
put_row.c:12:/*	buf is CELL *   WRAT code	*/
put_row.c:13:/*  int segment_put_row (SEGMENT *SEG, CELL *buf,int row) */

The "buf" arguments are actually "void *".

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