[GRASS5] working on g3d

[Glynn Clements]

Markus Neteler wrote:

> > I'm interested in continuing to help with this.  Its becoming a key part 
> > of our work integrating 3D geophysical inversion models with surface 
> > data.  We have even had some interest from the medical imaging community!
> 
> A suggestion concerning r3.mapcalc: 
> At time r.mapcalc and r3.mapcalc differ quite a bit as
> the latter is based on the old r.mapcalc implementation
> which was extended to a third dimension.
> 
> To somewhat simplify the future maintenance of r3.mapcalc,
> were it a good idea to extend the new r.mapcalc
> by 
> #define 3D
>   3D-related code
> #endif
> to a third dimension and replace the current r3.mapcalc?

Probably. I have looked into this previously, but didn't take any
action as:

a) there were known problems with the g3d code, and
b) I couldn't see an obvious way of dealing with the build issues.

> Of course this won't be done in an hour, but in the long
> run it may be the better solution.

The code changes shouldn't involve that much work.

The main problem is figuring out how to use the same source code to
build two separate programs. Ideally, the build process for
src/raster/r.mapcalc3 wouldn't require any changes. Options for
handling this include:

1. Build the common parts of r.mapcalc as a library, which both
r.mapcalc and r3.mapcalc use.

2. Have r.mapcalc itself to be built with g3d support if g3d was
enabled, so "r3.mapcalc ..." is effectively e.g. "r.mapcalc -3 ...". 

3. Have the r3.mapcalc build process copy/link the relevant source
files from r.mapcalc.

4. Have the r3.mapcalc build process use the relevant object files
from r.mapcalc.

Each of these has approaches has an associated drawback:

1. Yet another library.

2. Requires that the (optional) g3d library was built before
r.mapcalc.

3, 4. Messy, particularly allowing for out-of-place builds.

Option 1 seems the cleanest, but I'm open to comments.

As for the actual changes required:

1. map.c would be completely re-implemented for each version.

2. Most of the "primitives" (i.e. x*.c) would be common to both
programs (xcoor.c, xrowcol.c and xres.c might need to be extended
and/or changed).

3. Currently, evaluate.c and mapcalc.y would need some minor changes
between versions.

However, the need for changes in points 2 and 3 could probably be
eliminated by minor restructuring, i.e.:

a) Generalising some code (i.e. the main loops) to 3d; a 2d map would
be treated as a 3d map with a single plane.

b) Moving some code (opening/closing maps, querying the region) into
map.c.

c) Handling a 3d offset ("map[dx,dy,dz]") for a 2d map as a run-time
error, rather than a parsing error (so that mapcalc.y doesn't need any
changes).

Ideally, I'd like to reduce it to point 1: two versions of map.c, with
the rest of the code being identical.

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