<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<DEFANGED_meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Michael,<br>
<br>
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.<br>
<br>
Tom<br>
<br>
<br>
Michael Barton wrote:<br>
<blockquote type="cite"
cite="midA00B5248-AF9F-11D8-9DEA-000A956FE2E0@asu.edu">Craig,
<br>
<br>
I think your perspective is a good and pragmatic one. If I could echo
and build on a couple of your comments....
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
4. Your ideas on filters sound very good.
<br>
<br>
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. <br>
<br>
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
<br>
<br>
Michael
<br>
<br>
<br>
____________________
<br>
C. Michael Barton, Professor
<br>
School of Human Origins, Cultures, & Societies
<br>
PO Box 872402
<br>
Arizona State University
<br>
Tempe, AZ 85287-2402
<br>
USA
<br>
<br>
Phone: 480-965-6262
<br>
Fax: 480-965-7671
<br>
www: <<a class="moz-txt-link-abbreviated" href="http://www.public.asu.edu/~cmbarton">www.public.asu.edu/~cmbarton</a>>
<br>
On May 25, 2004, at 10:01 PM, Multiple recipients of list wrote:
<br>
<br>
<blockquote><b><!-- 0000,0000,0000 -->From:
</b>Craig Funk <a class="moz-txt-link-rfc2396E" href="mailto:funkmeister@lynxseismicdata.com"><funkmeister@lynxseismicdata.com></a>
<br>
<b><!-- 0000,0000,0000 -->Date: </b>May 25,
2004 3:20:33 PM MST
<br>
<b><!-- 0000,0000,0000 -->To:
</b><a class="moz-txt-link-abbreviated" href="mailto:grasslist@baylor.edu">grasslist@baylor.edu</a>
<br>
<b><!-- 0000,0000,0000 -->Subject:
[GRASSLIST:3492] Re: Geophysical/Potential field modules for
GRASS?
<br>
</b><br>
<br>
I will attempt to summarize the current thread,
<br>
<br>
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.
<br>
<br>
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
<br>
<br>
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?
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
My 2 cents worth:
<br>
<br>
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 ;)
<br>
<br>
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?
<br>
<br>
Cheers,
<br>
Craig
<br>
<br>
<br>
</blockquote>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177
EMAIL: <a class="moz-txt-link-abbreviated" href="mailto:thomas.adams@noaa.gov">thomas.adams@noaa.gov</a>
VOICE: 937-383-0528
FAX: 937-383-0033</pre>
</body>
</html>