[GRASS5] working on g3d wish list and testing
johnh at sjgeophysics.com
Fri Feb 28 17:29:59 EST 2003
Alfonso Vitti wrote:
>ok, more or less, this is where we are:
> (merging 2D files to 3D file and splitting 3D file to 2D layers)
>. merging "elevation" 2d surface to 3d file
> 1 = air (?)
> 0 = surface (?)
> -1 = soil (?)
> (e.g. geological fault surfaces)
We are looking at this area. So far I've been doing a lot of the 3D
slice and dice when I import from UBC-GIF format (the output of the 3D
inversion calculation). There would be value for geological users to
get arbitrary slices through the model and constant depth surfaces.
Note the last item there requries some way of identifying the
>. visualization - NVIZ - support of 3D raster
> (integration of sg4d or r3.showdspf functionality?
> (Tomas Paudits has started on this)
> (porting sg4d to i686-pc?)
Yes, very interested.
>. some sort of user interaction with 3d data on monitor
> (something like d.what.rast)
Something similar to the "probe" in vis5d to enable viewing a parameter
along a 1D line would be quite interesting.
>. data conversions between 3D vector (Grass5.1) and 3D raster format
Generation of pierce points from 3D vectors as a "site" on a 2D raster
would also be quite useful. Currently we are playing with ordered
series of 3D sites to simulate drill holes.
>. r3.out.v5d/r3.in.v5d with support of 5d data, i.e. time series of
> 3d data merged to v5d animation file
We have been looking at this to enable viewing individual iterations in
the convergence of inversion calculations.
>. r3.mapcalc add the capability to use also 2d-raster
Including the ability to use a topographic surface concept which would
allow the 2D raster to be draped within a r3.mapcalc operation.
>. r3.out.v5d always/sometimes(?) it reverses t-b, n-s order
I found the problem here last night. Vis5d stores b->t and it was being
loaded t->b in r3.out.v5d. How did I get this working for the
conference where we were demoing it last month? I think I must have
done Debug - Test - Cleanup code - Submit -
Wonder-why-it-stopped working! ;-)
So far I've seen production data run through s.vol.idw, r3.out.v5d,
vis5d, r3.mkdspf and r3.showdspf and everything came out right way
round. Also, subsets of 3d site files showed up correcly positioned in
Most of the testing I've been doing so far has been rather ad hoc, and
has usually involved current or past production data that I know well
enough to spot something mislocated. Has there been any more formalized
testing organized within the grass modules? Either at the "make test"
level or with a JUnit style approach. What do people think about the
appropriate level for test planning in grass?
More information about the grass-dev