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

[Craig Funk]

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 
interfaces?


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



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

Craig

> Best regards,
>
> Benjamin