[GRASS5] working on g3d wish list and testing

John Harrop johnh at sjgeophysics.com
Fri Feb 28 17:29:59 EST 2003


Alfonso Vitti wrote:

>ok, more or less, this is where we are:
>
>wish list 
>---------
>
>     (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 
topographic surface.

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

>
>known bugs
>----------
>
>.    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 
NVIZ.

Testing Strategy:

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?

John Harrop




More information about the grass-dev mailing list