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

Michael Barton michael.barton at asu.edu
Thu May 27 01:35:12 EDT 2004


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 at lynxseismicdata.com>
> Date: May 25, 2004 3:20:33 PM MST
> To: grasslist at 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
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 5781 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-user/attachments/20040526/a7f5f48f/attachment.bin


More information about the grass-user mailing list