[GRASS5] very confused over NULL in rasters

GRASS GRASS developer
1

Hello,

Still another question while revising r.le, which is especially
messy because of null values and true zeroes.

I am confused about what the possible cases are for null values
in a raster map and the corresponding null file.

1. Will NULL values be in the raster map itself?
The programming manual section 5.8.2.2 on NULL VALUES
says that "the NULL values will not be written to the raster map
itself; a zero will be written as a place holder." But, earlier (a
couple of pages back it says "Provide two methodologies for
accessing NULL values when reading maps: --embedding the
NULL value in the raster data buffers" and "All support functions
should assume that the data has embedded NULL values"
It seems that the first statement is wrong in the programming
manual, as NULL values can be embedded in the raster?

Since this seems contradictory, I looked at how r.null handles this.
Actually, r.null does embed "nan" in float/double rasters and
a large negative number (-2147483648.00000) in integer rasters.

Actually, the programming manual (section 5.8.2.2 NULL-values)
says "The bit pattern used for integer is the largest positive integer"
but r.null seems to lead to the largest negative integer on my
machine (Mandrake 7.2 on Intel).

So, am I right that NULL values can sometimes be embedded
only in the actual rasters? This could happen if the raster has
no accompanying null-value file?

What is the correct way to search for a null in the raster, since
it can apparently be "nan" "largest negative integer" etc. Does
this have to be done with a set of three cases, one each for
CELL, FCELL, DCELL? Does searching for "== NULL" get
all the possible cases?

I think the programming manual needs to be cleaned up so it
is more correct about this, or else so people like me don't
misunderstand it, as it seems to be contradictory. I can't
fix it though myself without knowing what is really right!

2. The NULL in the null value file (cell_misc/<map>/null) in the
programming manual is "one indicating that the corresponding
cell contains valid data, and zeros indicating that the corresponding
cell contains a NULL value. I may have done something wrong
when I looked at the results from using r.null, but I'm pretty sure
that program does just the opposite--a one indicates a null and
a zero indicates valid data. Is this wrong in the programming
manual or does r.null have it backwards? What are programmers
assuming is correct?

Bill Baker
Univ. of Wyoming
BAKERWL@UWYO.EDU

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

2

On Sat, Dec 16, 2000 at 02:36:02PM -0700, William L. Baker wrote:

Hello,

Still another question while revising r.le, which is especially
messy because of null values and true zeroes.

I am confused about what the possible cases are for null values
in a raster map and the corresponding null file.

1. Will NULL values be in the raster map itself?

[snip]

If you're using the library functions, you don't need to care whether
the NULL's are embedded or not. In memory they are embedded, on disk
they are separated. By using the library routines for testing for NULL
values or writing NULL values (by RASTER_MAP_TYPE), you shouldn't worry
about how they are actually dealt with. Huidae Cho suggested an nice
method for handling the abstraction for the differing kinds of rasters
that goes something like:

union RASTER_PTR {
  void *v;
  CELL *c;
  FCELL *f;
  DCELL *d;
};

struct RASTER_MAP_PTR {
  RASTER_MAP_TYPE type;
  union RASTER_PTR buf;
};

The you can use something like:

..
  struct RASTER_MAP_PTR rast;
  struct Cell_head window;

  rast.type = G_raster_map_type (name, mapset);
  rast.buf.v = G_allocate_raster_buf (rast.type);

  G_get_window (&window);

  ...
  
  for (i = 0; i < window.cols ; i++)
    switch (rast.type) {
      case CELL_TYPE:
        rast.buf.c[i] = /* something */
      ...

    }
  
  /* or */

  if (G_is_null_value (rast.buf.v, rast.type))
    /* Do something */

  /* or */

  G_set_null_value (rast.buf.v, window.cols, rast.type);
  
  G_free (rast.buf.v);
..
    

2. The NULL in the null value file (cell_misc/<map>/null) in the
programming manual is "one indicating that the corresponding
cell contains valid data, and zeros indicating that the corresponding
cell contains a NULL value. I may have done something wrong
when I looked at the results from using r.null, but I'm pretty sure
that program does just the opposite--a one indicates a null and
a zero indicates valid data. Is this wrong in the programming
manual or does r.null have it backwards? What are programmers
assuming is correct?

I haven't done alot of raster programming, but I've generally avoided
worrying about using NULL flags for G_insert_null_values() or whatever,
by simply setting an entire buffer to NULL and then writing non-NULL
values where applicable. For reading, I've used the G_is_null_value
to deal with whether a cell is NULL or not. I suppose using the flags
method could be more practical in some scenarios, and I believe you're
correct that 0 == not-NULL and 0 != NULL. At least, it says that for
G_insert_null_values();

--
Eric G. Miller <egm2@jps.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

3

Hi back on this thread,

just checked in a demonstration module from Huidae Cho
into
unused/raster/r.show

which demonstrated below FP programming with UNIONs
as described below.

Maybe useful to someone,

thanks, Huidae!

Markus

On Sat, Dec 16, 2000 at 02:40:20PM -0800, Eric G . Miller wrote:

On Sat, Dec 16, 2000 at 02:36:02PM -0700, William L. Baker wrote:
> Hello,
>
> Still another question while revising r.le, which is especially
> messy because of null values and true zeroes.
>
> I am confused about what the possible cases are for null values
> in a raster map and the corresponding null file.
>
> 1. Will NULL values be in the raster map itself?
[snip]

If you're using the library functions, you don't need to care whether
the NULL's are embedded or not. In memory they are embedded, on disk
they are separated. By using the library routines for testing for NULL
values or writing NULL values (by RASTER_MAP_TYPE), you shouldn't worry
about how they are actually dealt with. Huidae Cho suggested an nice
method for handling the abstraction for the differing kinds of rasters
that goes something like:

union RASTER_PTR {
  void *v;
  CELL *c;
  FCELL *f;
  DCELL *d;
};

struct RASTER_MAP_PTR {
  RASTER_MAP_TYPE type;
  union RASTER_PTR buf;
};

The you can use something like:

..
  struct RASTER_MAP_PTR rast;
  struct Cell_head window;

  rast.type = G_raster_map_type (name, mapset);
  rast.buf.v = G_allocate_raster_buf (rast.type);

  G_get_window (&window);

  ...
  
  for (i = 0; i < window.cols ; i++)
    switch (rast.type) {
      case CELL_TYPE:
        rast.buf.c[i] = /* something */
      ...

    }
  
  /* or */

  if (G_is_null_value (rast.buf.v, rast.type))
    /* Do something */

  /* or */

  G_set_null_value (rast.buf.v, window.cols, rast.type);
  
  G_free (rast.buf.v);
..
    
> 2. The NULL in the null value file (cell_misc/<map>/null) in the
> programming manual is "one indicating that the corresponding
> cell contains valid data, and zeros indicating that the corresponding
> cell contains a NULL value. I may have done something wrong
> when I looked at the results from using r.null, but I'm pretty sure
> that program does just the opposite--a one indicates a null and
> a zero indicates valid data. Is this wrong in the programming
> manual or does r.null have it backwards? What are programmers
> assuming is correct?

I haven't done alot of raster programming, but I've generally avoided
worrying about using NULL flags for G_insert_null_values() or whatever,
by simply setting an entire buffer to NULL and then writing non-NULL
values where applicable. For reading, I've used the G_is_null_value
to deal with whether a cell is NULL or not. I suppose using the flags
method could be more practical in some scenarios, and I believe you're
correct that 0 == not-NULL and 0 != NULL. At least, it says that for
G_insert_null_values();

--
Eric G. Miller <egm2@jps.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

--
Markus Neteler * University of Hannover
Institute of Physical Geography and Landscape Ecology
Schneiderberg 50 * D-30167 Hannover * Germany
Tel: ++49-(0)511-762-4494 Fax: -3984

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'