[GRASS5] 5.7: most r3.* modules included

[Glynn Clements]

Hamish wrote:

> > > For now I left r3.mapcalc out because the Makefile is
> > > not to be written straightaway. And once we talked about
> > > the idea of extending the new 2D r.mapcalc to a
> > > 3rd dimension with #defines to optionally compile
> > > it with two or three dimensions. As far as I remember
> > > basically all loops have to be extended to additionally
> > > browse the z direction.
> > > 
> > > If the expected time to extend the new 2D r.mapcalc to a
> > > 3rd dimension would be predicted with > 2 month, I
> > > suggest to include the old r3.mapcalc.
> > 
> > It shouldn't take more than a week at most, and probably just the time
> > taken to learn the relevant bits of the G3d API plus a day to
> > implement.
> 
> can this wait until after 5.3.0 is released?

Too late; I've just committed an update to r.mapcalc to support 3d
volumes. Testing would be appreciated.

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.

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.

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