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

[Michael Barton]

Craig,

I will write you directly as well as the list. Perhaps you can 
coordinate several of replies.

Most of the things being requested below already exist in GRASS. I will 
comment briefly but will be happy to expand if you'd like. As is the 
gist of the comments below, I'll focus on GRASS 5.7.

1. I agree with Benjamin about device drivers. These are a lot of 
trouble and beyond what a GIS is designed to do. They have to be 
platform-specific and device-specific to be useful. On the other hand, 
most data collectors for geophysical data produce standard ascii output 
files (e.g., csv). These CAN be read into GRASS using v.in.ascii.

2. The idea of a GIS is to have an integrated data management system. 
This is quite good in GRASS 5.7. Internally it uses dbf files. This 
would be more than sufficient for standard geophysical data and easily 
readable by a variety of other common programs (e.g., Excel, Access, 
Filemaker). However, as someone pointed out below, 5.7 also has easy 
links to other database systems like MySQL and PostgreSQL.

3.  A ...
>>   mesh of adjacent, regular measurement grids with dimension,
>>   orientation and origin in reference to the working location

...is provided by the GRASS raster data model. It is a regular grid by 
default and you can specify the size of each grid in the g.region 
module. Point data can be easily attached to the grid, though a simple 
script might make this easier.

If the original data are not oriented according to geographic 
directions, they can be imported into an XY location. If a set of 
points are known that relate an arbitrary XY location to a 
georeferenced (i.e., real world) grid system, GRASS provides tools 
(i.rectify, v.transform, r.proj,  v.proj) to georeference the original 
working grid so that it can be combined with any other grids.

4. GRASS has a series of fairly sophisticated filter modules. More 
could be written if there are specific ones for particular kinds of 
uses. The ones that exist include: r.neighbor (many neighborhood 
functions like mean, median, diversity, etc.), r.mfilter (user-defined 
matrix/convolving filter), i.fft and i.ifft (fast fourier transform), 
and i.zc (zero-crossing edge detection). It also includes a reasonably 
decent set of image classification (supervised and unsupervised) and 
analysis functions (e.g., pca, cannonical components analysis, tassled 
cap and brovey transformations, etc.). Of course, there are all the 
other many raster and vector analysis modules that can be applied to 
multiple grids.

5. r.colors gives very flexible and powerful ways to create and modify 
color tables across the grids. You can specify by values, ranges of 
values, percents of total, etc. using standard GRASS colors and/or rgb 
triplets.

6. On top of this, you can easily render any grid and vector data into 
2.5 D surfaces using NVIZ, AND you can create true 3D volumes using the 
Grid3D modules. The latter still need to be better developed but are as 
or more sophisticated than anything else I know of in a GIS package. 3D 
volumes can also be displayed and manipulated in NVIZ. Finally, using 
NVIZ, you can create 'fly-through' key frame animations.

I am sure that GRASS could benefit from new modules or shell scripts 
that could enhance its ability to be used in geophysical analysis 
(e.g., new filters or scripts to automate the import and georeferencing 
of XY data). However, it interesting that it already does all the 
things requested below.

Michael Barton
______________________________
Michael Barton, Professor & Curator
School of Human Origins, Cultures, & Societies
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
On May 25, 2004, at 11:49 AM, Craig Funk wrote:

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