[GRASS5] r.neighbors: works with reclass maps?

[Glynn Clements]

Markus Neteler wrote:

> while using r.neighbors on reclassed maps (from r.reclass)
> I got some strange results.

Are you referring to the result map being almost entirely null?

E.g.

	r.neighbors -z input=soils.Kfactor output=foo method=minimum size=5

produces a map which is null except for the very left-hand edge, while

	r.mapcalc 'sk=soils.Kfactor'
	r.neighbors -z input=sk output=foo method=minimum size=5

seems to work OK.

> Is it possible that we have
> to added a test into r.neighbors? Or is it a local problem
> only?

The bug is in libgis.

The call to G_get_d_raster_row() in readcell.c returns only NaN for
the original (reclass) "soils.Kfactor" map, but sensible values for
the (non-reclass) "sk" map.

I've tracked this down to the double use of a static buffer
(G__.mask_buf) in G_get_raster_row().

For reclass maps, G_get_raster_row() uses G__.mask_buf as a temporary
buffer. It calls G_get_c_raster_row(G__.mask_buf), which in turn calls
embed_nulls(G__.mask_buf), which calls G_get_null_value_row(). 
However, G_get_null_value_row uses G__.mask_buf itself (via the macro
MASK_BUF) to hold the mask row.

Summary: static "work buffers" are a bad idea.

Unfortunately, some systems don't support alloca(), and some of those
which do don't make it straightforward to use. autoconf has a
solution, but it's messy. And using malloc()/free() for short-lived
buffers could significantly harm performance.

For the time being, I guess that we'll have to just add another static
work buffer for the purpose of reclass maps. However, I'm not yet sure
of the mechanism used for allocating and reallocating such buffers.

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