[GRASS5] 5.7: most r3.* modules included

[Markus Neteler]

On Tue, May 11, 2004 at 08:19:09AM +0100, Glynn Clements wrote:
[...]
> Too late; I've just committed an update to r.mapcalc to support 3d
> volumes. Testing would be appreciated.

Great - impressive response time! Thanks for your efforts.
 
> Building src/raster/r.mapcalc3 will now generate both r.mapcalc and
> r3.mapcalc. r3.mapcalc uses the 3d region and reads and writes G3d
> volumes, but is otherwise identical to r.mapcalc.
> 
> Almost everything is shared, except that there are 3d versions of
> map.c (the core map-handling functions), xcoor.c (the x(), y() and z()
> functions) and xres.c (the ewres(), nsres() and tbres() functions).
> 
> Some points to note:
> 
> 1. The two programs accept the same language, with the same set of
> functions. Using the third dimension in r.mapcalc has reasonable
> (IMHO) behaviour: z() and tbres() always return NULL, depth() always
> returns 1, and using the third dimension in a neighbourhood modifier
> (i.e. map[x,y,z] where z is non-zero) will always return 1. IOW, a 2d
> map is essentially treated as a 3d map where depths=1 and the region's
> top/bottom are NULL.

A related question: A long-standing wish was to have access to 2D maps
within r3.mapcalc (old version). Does the new implementation permit
to access 2D and 3D raster at the same time?

Background idea: get amount of rainfall from 2D map, then feed the 
volume model to percolate the water within the volume using these
"seed" cell values.


> 2. G3d doesn't support integer values. Input maps are always float or
> double; creating a map from an integer-valued expression will result
> in it being promoted to double.
> 
> 3. There doesn't appear to be a G3d equivalent of G_unopen_cell(),
> which is used to "uncreate" a map if an error occurs.
> 
> 4. I've just remembered that this won't work on 64-bit platforms yet;
> I fudged the fact that G3d uses void* for handles (as opposed to int
> for libgis) by stuffing the void* into an int. If
> sizeof(void*)>sizeof(int), you lose. This will be fixed in due course.

Maybe Jaro or Helena have a comment here, they are closest to the
original development/developers.

Markus