[GRASS5] working on g3d

[Markus Neteler]

On Thu, Feb 27, 2003 at 08:18:46PM +0000, Glynn Clements wrote:
> Markus Neteler wrote:
[...]
> > 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:

Note (you will know that already, Glynn):
r.terraflow is building two versions from shared code with compile flags.

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

Maybe yes, and this code might be interesting for other modules
as well (r.neighbors etc).

> 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.

Yes and no: There is the gmath lib and parts of libgis which should
be merged in the long run. r.mapcalc code could contribute.

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

which should be no big issue as it does not have external
dependencies (hope I am right).

> 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.

Markus