[GRASSLIST:3488] Re: Geophysical/Potential field modules for GRASS?

Tue May 25 12:52:48 EDT 2004

(First of all: my apologies for the length of this message
 and my inability to say more with fewer words)

Thanks to everyone who joined in to the discussion
about GRASS and geophysics so far. I think this is an
issue that a lot of us are interested in.

A valid point by Syd: if we go through all the work of creating
a full set of GRASS modules, we will want to make sure that we
use the full power of GRASS data integration, not just create
a bunch of disconnected tools, each one with a different set
of command line parameters.
My ideas of a GRASS-based geophysics workflow include:

( - possibly provide device drivers to read measurement
    data from the serial interface in the field )

- provide a consistent storage for raw measurement data as
  dedicated database elements in the working location. 
  This way I won't have my
  ASCII files floating around random folders in the file
  system and can always fall back to the original data

- provide a simple and comfortable way of setting up a mesh
  of adjacent, regular measurement grids with dimension, 
  orientation and origin in reference to the working location.
  Each raw measurements file could then be referenced to
  this mesh by simply specifying its row and column location

- a set of modules to apply filters to any GRASS raster map
  These modules should share a common set of command line
  parameters and instead of applying filters immediately,
  store each filter and its parameters in a processing list.
  The processing list should be a simple ASCII file, which
  in turn resides in its own database element

- a set of modules (possibly a simple GUI) to manipulate
  the processing list, ensuring that only valid filters
  and parameters get written into it

- a set of modules to easily manipulate the color ramp
  for the entire mesh

- For the final output:
  a module to create a GRASS raster map from the ENTIRE mesh:

  1. read the individual raw data files associated with
  each grid location,
  2. convert each individual grid to a GRASS raster map and
  store it in a cache database element
  3. apply all specified filters in the processing list and
  color ramps to the grid maps
  4. Patch grids together into one GRASS raster map
  5. rotate and move the entire thing to the specified origin 
  in the working location, 

This is what I would prefer to have it done like, based
on my field experience with gradiometer and caesium data.
I don't know a whole lot about other geophysics and have
left out any plotting capability for e.g. resistivity
data or geo-electrics.
So, what do you think should be added/changed about this concept?
I would like us to assemble a white paper on targeted workflow
and functionality asap, so we can, as a next step, decide
on what technology to use.

Best regards,

Benjamin

On Tue, 25 May 2004 14:28:39 +0000 (UTC)
Syd Visser <sydv at sjgeophysics.com> wrote:

> Benjamin Ducke <benducke <at> compuserve.de> writes:
> 
> > 
> > As an archaeologist, I also work with geophysical data
> > regularly (especially gradiometer data). So far,  I have used proprietary 
> software,
> > such as Geoplot to view and filter data (trend removal/destriping, low/high 
> pass filters etc.).
> > But I think that GRASS is, in principle, an ideal platform
> > for such tasks. I have already spent some time laying out an infrastructure 
> for
> > geophysical data processing with GRASS.
> > I have also made plans to create some module myself - in the near future ;)
> > The wonderfull "Scientific Applications on Linux" web repository 
> (http://sal.jyu.fi/index.shtml)
> > has a category for "Computer Graphics, Images & Signals: Processing & 
> Visualization".
> > In it, I found a link to the "XITE" image processing tools.
> > XITE also has an open source C library that seems to have ever imaginable
> > high-level functionality one would need.
> > I think one could get started ang get functionality very quickly by 
> integrating this library with
> > GRASS.
> > So, if there is any serious interest in getting GRASS up to par with Imagine 
> and the like,
> > maybe we should pull forces together and start coding?
> > Anyone else interested in this sort of functionality?
> > 
> > Cheers,
> > 
> > Benjamin.
> > 
> > On Fri, 21 May 2004 10:50:41 -0600
> > Funkmeister <funkmeister <at> lynxseismicdata.com> wrote:
> > 
> > > Hello, I will need to process/interpret some geophysical data (gravity, 
> > > mag) and I would like to use GRASS for this purpose. Is anyone aware of 
> > > any modules available for GRASS? I need to do things like trend 
> > > removal, terrian corrections, Bouguer correction, reduction to pole, 
> > > downward continuation, etc. I will also need to apply any number of 2-D 
> > > filters.
> > > 
> > > If there are no suitable modules, I will likely write them. So please 
> > > also let me know if anyone else is interested in such modules, and 
> > > features that would be desired.
> > > 
> > > Thank you,
> > > Craig
> > > 
> > 
> > 
> 
> this is the first time i have added a message to this user group and i hope it 
> gets there this time i have been rejected 3 times for different reasons.
> 
> We are a geophysical contracting and consulting company and make use of 
> proprietary, in-house and opensource software to do our data processing and 
> interpretation. We also specialize in doing 3D inversions of magnetic, gravity 
> and IP data on our in-house cluster using software developed by UBC and 
> modified for our use.
> We are trying to move over to using opensource packages like grass, VTK etc to 
> process and display data and are looking for funding to carry this forward a 
> extra step. As you mentioned there is a lot of free software available. A other 
> place that I can think of is at the USGS site http://pubs.usgs.gov/fs/fs-0076-
> 95/FS076-95.html. The problem or at least i think the problem is not only 
> finding the free available software but putting it together into a useful 
> package. We would certainly like to see any geophysical, potential field, 
> functionality added to a package like grass. Although we are extremely busy at 
> this point we would try to help anyone starting such a project.
> 
> Syd
> www.sjgeophysics.com
> 
> 