[GRASS5] working on g3d

GRASS GIS GRASS GIS developer
1

ok, more or less, this is where we are:

wish list
---------

. r3.flow (almoste done, Jaro Hofierka)
     3D flowtracing module
. s.volt.rst (almost done, Jaro Hofierka)
     4D interpolation with saviong time series of g3d volumes or 2d
     intersection files
. link/conversion to and from 2D data
     (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)
. visualization - NVIZ - support of 3D raster
     (integration of sg4d or r3.showdspf functionality?)
     (Tomas Paudits has started on this)
     (porting sg4d to i686-pc?)
. some sort of user interaction with 3d data on monitor
     (something like d.what.rast)
. support of time series (needed also for 2d data), naming
     conventions?
. data conversions between 3D vector (Grass5.1) and 3D raster format
. r3.stats
. r3.recode
. r3.what
. r3.out.v5d/r3.in.v5d with support of 5d data, i.e. time series of
     3d data merged to v5d animation file
. r3.proj?
. xganim - support of 3d data animation?
. add the possibility to define in the volume "boundaries surfaces"
     (support to regionally restricted interpolation/analysis)
     [keeping soil horizon boundaries or stratifications]
. hist files
. r3.mapcalc add the capability to use also 2d-raster
. r3.mapcalc add absolute cell reference
. temporal series and 4D data format, compression...
. export to netcdf format
     (a 2D version already exist, written by Alessandro Frigeri,
     Generic Mapping Tools and Explorer-OpenDX are supported)

g3d libraries
-------------

two tipe of functions can be defined:
tiles-functions and no-tile-functions

. now (I hope) all the parameters in the no-tile-functions are called
     in the order:
     rows, cols, levels
     iven if sometimes the notation
     y, x, z
     is used
. the parameters in the tile-functions are called in the order:
     x, y, z
     iven if sometimes the notation
     cols, rows, levels
     is used

known bugs
----------

. r3.mapcalc crash increasing the number of levels (error in
     G3d_getTilePtr)
. r3.mask crash (error in G3d_getTilePtr)
. r3.showdspf some parameters don't work
. r3.out.v5d always/sometimes(?) it reverses t-b, n-s order

discussion
----------

. extend the new r.mapcalc to a third dimension and replace the
     current r3.mapcalc
. for loops: levels, rows, cols
     (once for all, let's define them)
. do the tile-functions (see above) have to use x,y,z notation or
     could/should it be
     moved to rows,cols,levs?
. tiles support/use/performance
. update docs, bugs, todo files in src.contrib/GMSL/g3d

Alfonso

2

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! :wink:

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

3

. visualization - NVIZ - support of 3D raster
     (integration of sg4d or r3.showdspf functionality?)
     (Tomas Paudits has started on this)
     (porting sg4d to i686-pc?)

a small clarification here: sg4d is just a rather crude linkage of SG3d
and showdspf
which was the GL version of r3.showdspf. So there is no point of
integrating
or porting sg4d as SG3d has already been replaced by NVIZ (which is much
more powerfull now)
and showdspf was ported as r3.showdspf. So to make it work there are
several options:

1. integrate r3.showdspf with NVIZ (that was our original intention, but
Bill had troubles with that)
also, r3.showdspf has disabled an important functionality that allowed
to create solids and
crossections (this was probably due to the bug in g3d library which
should be fixed by now
so it may be worth revisiting).

2. Forget r3.showdpsf and write support for 3D raster for NVIZ from
scratch

3. Use vis5d

. xganim - support of 3d data animation?

do you mean here something like slicing through the volume (equivalent
to transforming the 3d raster to seriers of 2d rasters and then running
them
through xganim) ? We did 3d data animation either through showdspf or
through scripting
in sg4d (using the SG3d scripting capability). Nviz already has lots of
scripting/animation
tools but they are not particularly easy to use.

. add the possibility to define in the volume "boundaries surfaces"
     (support to regionally restricted interpolation/analysis)
     [keeping soil horizon boundaries or stratifications]

isn't this supported by r3.mask? But the tools to create such mask could
be
expanded by the r3.mapcalc extensions as suggested below

. hist files
. r3.mapcalc add the capability to use also 2d-raster
. r3.mapcalc add absolute cell reference
. temporal series and 4D data format, compression...
. export to netcdf format
     (a 2D version already exist, written by Alessandro Frigeri,
     Generic Mapping Tools and Explorer-OpenDX are supported)

g3d libraries
-------------

two tipe of functions can be defined:
tiles-functions and no-tile-functions

. now (I hope) all the parameters in the no-tile-functions are called
     in the order:
     rows, cols, levels
                 iven if sometimes the notation
                 y, x, z
                 is used
. the parameters in the tile-functions are called in the order:
     x, y, z
     iven if sometimes the notation
     cols, rows, levels
     is used

would it be difficult to unify this ?

known bugs
----------

. r3.mapcalc crash increasing the number of levels (error in
     G3d_getTilePtr)
. r3.mask crash (error in G3d_getTilePtr)
. r3.showdspf some parameters don't work
. r3.out.v5d always/sometimes(?) it reverses t-b, n-s order

is there still a problem with s.vol.rst? (John was reporting some
segmentation faults)

discussion
----------

. extend the new r.mapcalc to a third dimension and replace the
     current r3.mapcalc
. for loops: levels, rows, cols
     (once for all, let's define them)
. do the tile-functions (see above) have to use x,y,z notation or
     could/should it be
     moved to rows,cols,levs?

I would suggest rows, cols levs to minimize the confusion

. tiles support/use/performance
. update docs, bugs, todo files in src.contrib/GMSL/g3d

Alfonso

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