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

[Craig Funk]

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