Craig,
I think your perspective is a good and pragmatic one. If I could echo and build on a couple of your comments....
2. The current database module in GRASS 5.7 is inherently relational with a built-in SQL query engine. But you don't have to use the relational capacity and most of the discussion I've seen so far does not require a relational model.
3. The most straightforward way to get point data into grid format is through interpolation. GRASS has some pretty good interpolation modules. But there is a big hole in its lack of Krieging. In the sites modules for GRASS 5.3 there are commands to calculate the semivariance of a point scatter and to fit a semivariagram from this point set to various models (s.sv and s.svfit). These could be updated to vector point formats for GRASS 5.7 as the start of a Krieging module. Apparently there is/was a Krieging module because there is a man page for s.surf.krieg, but it doesn't normally compile. There are also some other sites modules for getting point data to grids in alternative ways. Examples include s.windavg, s.kernel (this has been translated to v.kernel for 5.7), s,medp (median polish), etc. These could all be updated to GRASS 5.7, providing a rich point to grid toolkit.
4. Your ideas on filters sound very good.
5. Color management is quite flexible and relatively easy to modify. For example, if you'd like to make a color table tied to standard deviations around a mean, you can use r.statistics to generate a mean and standard deviation and redirect output to a file or script, where you could reformat those values into a color table, which could in turn be redirected into r.colors to create the needed color table. From an interactive standpoint, r.colors is not point and click (something I'd like to see eventually), but is very easy to use interactively.
A little programming to put a friendlier face on these would go a long way, as you suggest. I am happy to contribute. I've got a wish list I am happy to share. Sounds like this will be a very useful project for many people
Michael
____________________
C. Michael Barton, Professor
School of Human Origins, Cultures, & Societies
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA
Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>
On May 25, 2004, at 10:01 PM, Multiple recipients of list wrote:
From: Craig Funk <funkmeister@lynxseismicdata.com>
Date: May 25, 2004 3:20:33 PM MST
To: grasslist@baylor.edu
Subject: [GRASSLIST:3492] Re: Geophysical/Potential field modules for GRASS?I will attempt to summarize the current thread,
1) Device interfaces to field instruments would be a *nice to have* but the functionality is already there. although that requires a few extra steps. As I indicated previously - my experience is limited - device drivers on windows is a mess. Not nearly as simple as Linux.
2) Database means GRASS database not relational. I don't think a relational database would add any value, it would probably make it more difficult to move data around. You can't just zip it up and mail it for example. And for large datasets there would be considerable overhead when loading the data. So GRASS file systems is the best approach
3) The raster data model is the way to go. Michael, how do you associate point data with a raster grid? Also would the GRASS architects (Neteler et al.) frown on adding new database structures?
4) GRASS has many powerful filtering modules. Any convolution based filter can be realized through r.mfilter, and r.mapcalc can be used to implement many filters. However there seems to be a need for a more seamless "integration" of filters. Also specific corrections - like the terrain correction - do not exist. To implement such a correction with r.mapcalc would be tedious. I think this is where the white paper could be useful in that it should highlight the filters that are needed for geophysical apps; identify those filters that already exist in GRASS; and then we are left with the filters/corrections that need to be implemented.
I really like the idea of the filtering stream (Benjamin). Maybe this could be a new GRASS module that is a seamless front end to existing GRASS modules and possibly some yet-to-be-determined modules. For example a commonly applied low pass 2-D filter would be predefined in this module without having to write the kernel function in an ASCII file. It would call r.mfilter on the users behalf with the predefined kernel function. Also by having a schema and an XML structure these streams should be easy to manage - maybe even just store in the database. For new/casual users this would be probably simplify their GRASS experience/barrier to use. This module would also have many other uses to all types of raster data.
5) Color management routines exist, but they could maybe use some improvement. I have not looked into this personally so I am speculating here, but other users (non-geophysical) would also likely be interested in an easy-to-use color map generating module.
My 2 cents worth:
I think it is always best to start small and build from there. So it is important to get the architecture right from the start. Plus if my boss sees some results early, he will be willing to continue funding of my portion of the work
Also a white paper would be a very nice way of starting this, anyone have a document we can start with? *or* I can just start one based on this thread. How about a Wikki?
Cheers,
Craig
