[GRASS-dev] GRASS-Ctypes: Unable to trap null values in Raster

[Glynn Clements]

Sudipta Sarkar wrote:

> I am trying to check for null values in input raster files using Python Ctypes interfaces.
> First of all I am not sure how you do this using Ctypes. Heres what I am doing:
> ...............
> for row_n in range(rows):
> 	# read a row of raster data into memory, then print it
> 	Rast_get_row(in_fd, in_rast, row_n, data_type)
> 	# Check for null value
> 	for col_n in range(cols):
> 		if(Rast_is_d_null_value(pointer(c_double(in_rast[col_n])))):
> 			in_rast[col_n] = 0.0
> 
> But this does not work as for all null values in the input raster
> map I am getting some value of "-2147483648" in my input buffer so
> the above check is failing. What am i doing wrong here and whats the
> best way to trap null values in input raster using Ctypes libraries? 
> I suspect that value of "-2147483648" is probably some sort of
> string/ascii representation of "Null" but am not sure whats causing
> this conversion and how to avoid that and just trap null values
> plain and simple.

You're reading the data as CELL (int) then converting to DCELL
(double) without checking for nulls first. This won't work.

GRASS uses -2147483648 as the null value for CELL data. 
Rast_is_c_null_value() and Rast_is_null_value(..., CELL_TYPE) will
return true for this value.

The null value for FCELL/DCELL data is NaN.

In general, if you want to convert a value from one type to another,
you have to explicitly check for nulls (before converting), or use the
conversion functions which GRASS provides:

	CELL Rast_get_c_value(const void *, RASTER_MAP_TYPE);
	FCELL Rast_get_f_value(const void *, RASTER_MAP_TYPE);
	DCELL Rast_get_d_value(const void *, RASTER_MAP_TYPE);

	void Rast_set_c_value(void *, CELL, RASTER_MAP_TYPE);
	void Rast_set_f_value(void *, FCELL, RASTER_MAP_TYPE);
	void Rast_set_d_value(void *, DCELL, RASTER_MAP_TYPE);

But in most cases, you're usually better off simply reading the data
as DCELL. This will convert null values correctly.

-- 
Glynn Clements <glynn at gclements.plus.com>