[GRASS5] working on g3d

GRASS GRASS developer
1

Hi everybody working on g3d libs and r3.* modules!

I wonder if we can make the point on the GRASS 3D-raster support.
I've been thinking that knowing who is working on and/or interested in
GRASS 3D-raster support could be useful to plan the development of this
part of GRASS.

some topics could be:

current status of g3d libs;
known 3D-raster modules bugs (also related to the bugs in the g3d libs);
define some standards for development (also usefull to clean libs and
modules);
todo and development;
current applications;

It's not all here, I'm certainly forgetting something, please add it.

I think that a better coordination can result in overall efficiency

Alfonso

Alfonso Vitti
phd student
Departement of Civil and Environmental Engineering
University of Trento -Italy-

2

Hi Alfonso,

thanks for this initiave! Please add me to the list of g3d people. Also, it would be fine to update grid3d information on grass web
page using gathered information. Maybe you can prepare initial page with themes and your own suggestions.
I will prepare and send you my ideas.

Jaro

Alfonso Vitti wrote:

Hi everybody working on g3d libs and r3.* modules!

I wonder if we can make the point on the GRASS 3D-raster support.
I've been thinking that knowing who is working on and/or interested in
GRASS 3D-raster support could be useful to plan the development of this
part of GRASS.

some topics could be:

current status of g3d libs;
known 3D-raster modules bugs (also related to the bugs in the g3d libs);
define some standards for development (also usefull to clean libs and
modules);
todo and development;
current applications;

It's not all here, I'm certainly forgetting something, please add it.

I think that a better coordination can result in overall efficiency

Alfonso

Alfonso Vitti
phd student Departement of Civil and Environmental Engineering University of Trento -Italy-

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

3

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!

I'm working on testing modules as we need to use them. That is the main priority for us, but I do look at other things on the way through.

I think your suggestion is also timely because of the eventual move to 5.1 and with all our time and effort being limited it would be good to maximize its long term value.

Cheers,
John Harrop

Alfonso Vitti wrote:

Hi everybody working on g3d libs and r3.* modules!

I wonder if we can make the point on the GRASS 3D-raster support.
I've been thinking that knowing who is working on and/or interested in
GRASS 3D-raster support could be useful to plan the development of this
part of GRASS.

some topics could be:

current status of g3d libs;
known 3D-raster modules bugs (also related to the bugs in the g3d libs);
define some standards for development (also usefull to clean libs and
modules);
todo and development;
current applications;

It's not all here, I'm certainly forgetting something, please add it.

I think that a better coordination can result in overall efficiency

Alfonso

Alfonso Vitti
phd student Departement of Civil and Environmental Engineering University of Trento -Italy-

4

"make htmldocs" fails on 5.1 under Solaris 8 Sparc because the "type"
command does not accept the "-p" switch. It can be fixed by changing
"type -p" to "type" in /lib/db/Makefile and /lib/vector/Makefile.

5

On Wed, Feb 26, 2003 at 05:48:38PM -0800, cheg01@attbi.com wrote:

"make htmldocs" fails on 5.1 under Solaris 8 Sparc because the "type"
command does not accept the "-p" switch. It can be fixed by changing
"type -p" to "type" in /lib/db/Makefile and /lib/vector/Makefile.

Ok, I have tested on Linux and submitted the proposed change.

Markus

6

On Wed, Feb 26, 2003 at 02:39:23PM -0800, John Harrop 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?

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

Just my 0.02 Euro

Markus

7

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@virgin.net>

8

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

9

Markus Neteler wrote:

> 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):

Actually I didn't.

r.terraflow is building two versions from shared code with compile flags.

I use the alternate build system almost exclusively[1], so r.terraflow
doesn't build anything; it just fails because r.terraflow/Gmakefile
(uniquely) has its own compilation rules.

[1] The only exception is if I specifically want to test the "normal"
build system.

r.terraflow/Gmakefile also relies upon features of GNU make, so it
won't work with other make programs.

BTW, has anyone tried building r.terraflow on anything other than
Linux?

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

The code in question isn't really useful for anything other than
r.mapcalc/r3.mapcalc.

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

OK; actually g3d isn't optional. s.vol.rst is built by default, and
s.vol.rst/Gmakefile specifically builds src/libes/g3d.

So, making r.mapcalc depend upon g3d is technically feasible. Although
whether it's a good idea is a different question. Doing so would
effectively turn g3d into core functionality.

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