[GRASSLIST:3505] Re: Geophysical/Potential field modules for
Thomas.Adams at noaa.gov
Thu May 27 07:36:50 EDT 2004
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.
Michael Barton wrote:
> 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
> 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
> C. Michael Barton, Professor
> School of Human Origins, Cultures, & Societies
> PO Box 872402
> Arizona State University
> Tempe, AZ 85287-2402
> 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
> 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?
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177
EMAIL: thomas.adams at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the grass-user