[GRASS5] very confused over NULL in rasters

[William L. Baker]

Unfortunately,  I cannot simply use the library functions.
r.le reads in the whole raster and works with it internally,
deciding what values constitute a "patch" and then
tracing the boundaries of it etc.

Life would be simpler if GRASS had library functions 
to do all the things that are needed to make r.le work!

So, I need to know the actual representation of null in
the raster itself and in the null-value file from bringing it
in with G_get_null_value_row.

Thanks for your thoughts though!

Bill Baker

-----Original Message-----
From: Eric G . Miller [mailto:egm2 at jps.net]
Sent: Saturday, December 16, 2000 3:40 PM
To: 'grass5 at geog.uni-hannover.de'
Subject: Re: [GRASS5] very confused over NULL in rasters


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 at jps.net>

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

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