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

[Thomas Adams]

Michael,

You mentioned a lack of Kriging capabilities in GRASS. Maybe I'm being 
naieve, or I don't understand the issue, but I have used R and GSTAT 
quite successfully for spatial interpolation within GRASS. So, I don't 
understand where the deficiencies lie unless you wanted GRASS modules 
per se for kriging; I guess I don't see a real advantage in that.

Tom


Michael Barton wrote:

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

-- 
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177

EMAIL:	thomas.adams at noaa.gov

VOICE:	937-383-0528
FAX:	937-383-0033

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-user/attachments/20040527/b0c2ee73/attachment.html