[GRASSLIST:3489] Re: Geophysical/Potential field modules for GRASS?
funkmeister at lynxseismicdata.com
Tue May 25 14:49:27 EDT 2004
Well I underestimated how much interest there is in geophysics apps. I
am rather new to GRASS but I also feel that GRASS is an ideal platform
for such apps.
I think the white paper is a great idea - and it will serve as a nice
working document to keep efforts coordinated and development on target.
I am a Geophysicist with a strong programming and database background
and my employer is quite open to the idea of developing some modules
for GRASS. The oil industry is also very profitable now - so the timing
is good. It would be really nice if other people could get involved
with development. We are a very small company so to begin with I have
to focus on meeting my/employers immediate needs. And I am hoping that
this effort won't be wasted. So by coordinating needs and documenting
them in the form of a white paper, development can proceed without
having to do things over again at a latter time.
Getting the framework right from the start is essential. That way it is
easy for others contribute to it, and the software can grow nicely
without other having to reinvent the wheel. I also feel that that we
should start with GRASS 5.7 because of it's seamless integration with
ODBC, MySQL, Postgres and others...Any comments on this?
My comments are dispersed below:
On 25-May-04, at 10:52 AM, Benjamin Ducke wrote:
> (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 )
I have limited experience with device drivers - but I do know that it
can be a pain because of platform issues. It might be smart to approach
the problem like GRASS does with the display drivers. Develop a device
independent protocol and then write platform specific "drivers" that
know how to communicate with the OS, and the field devices.
For example Mac OS X could be really problematic because new Macs do
not have serial ports and I assume that most field devices use a serial
port for communication. I could be wrong here...is there USB
> - 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
Where you thinking about a file system database here, or a relational
database? It would be really nice if this could be transparent to the
end user - like in GRASS 5.7. Where you choose your driver and then
don't worry about where the data is actually stored.
> - 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
I think this would be critical to seamless data import.
> - 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
XML might be ideal for this? (processing list).
> - a set of modules (possibly a simple GUI) to manipulate
> the processing list, ensuring that only valid filters
> and parameters get written into it
This could work much like the new GUI for GRASS, where each processing
element would be synonymous with a layer. When one clicks on a node a
panel would be populated with the attributes of that node and the user
could edit them. As long as all the filters share a similar schema,
this should be fairly straight forward to implement.
> - a set of modules to easily manipulate the color ramp
> for the entire mesh
I have not taken the time to look at this but it would seem like many
GRASS users could benefit from such a module if one does not exist.
> - 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.
I also do not have a need to work with Resistivity however we do work
with seismic reflection data quite a bit. WRT 2-D seismic - I would
likely use other software to process and interpret the data. Then I
would import time/depth picks as site/vector data and use krigging or
other interpolation methods to obtain DEM's. Many tools from R could
probably be used to work with 2-D data - although I have not looked at
> 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.
I'm in, I have goals I need to meet for my work in the near term
however I think the white paper is a great idea and is essential to
getting the architecture right from the start.
> Best regards,
More information about the grass-user