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
