[GRASSLIST:3492] Re: Geophysical/Potential field modules for GRASS?
funkmeister at lynxseismicdata.com
Tue May 25 18:20:33 EDT 2004
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
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?
More information about the grass-user