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

[Hamish]

> For the geophysical survey I've had been involved with (admittedly
> limited), the scale is too small for GPS to be of use unless high
> resolution differential correction is applied (data points along
> transects separated by centimeters and transects separated by a few
> meters). The grid is set up in advance, however (a luxury you don't
> have at sea). So the xy coordinate values have to assigned by 'dead
> reckoning' based on the predefined transect grid.

Ok.
We do set up transects in advance btw, it's just the boat doesn't always
want to go in a straight line.


> I haven't used Matlab or Octave, but I suppose they could do this kind
> of transformation. It's pretty straightforward in a spreadsheet.

But not automated, is susceptible to typos, and it isn't as easy to pass
off to a student to use.


> However, if this is the common way this kind of work is done for
> magnetometry, resistivity, conductivity, and GPR, then it would
> feasible to design some kind of pre-processing module.

I was thinking a script could be made around r.profile/r.transect -g.

eg:
g.mkgrid.sh start_point=e,n size=1 columns=25 rows=30 rotation=360

To make a 30x25 grid of 1m cells, with one corner at [e,n] and oriented
X degrees from true North.

It could output either a set of coordinates in a sites/points file, a
vector file like v.mkgrid, etc. depending on your needs.

Use r.transect to get the x coordinates, then run again to get the y
coordinates, then fill in the blanks. Or if rotated, use the results
from the first profile as starting points for running r.transect again
for each 'y' line sequentially.

It would probably need r.profiles's res= option ported to r.transect,
and maybe a dummy raster to use as a backdrop if you didn't want to make
a new C module.

It's all possible.. good luck.



> What I don't know is the extent to which the ascii output from
> the relevant data recorders used by different manufacturers is 
> sufficiently standardized so as to plug into such a module. If
> everyone records 'new transect' and 'data point' in very different
> ways, this could be difficult as you suggest.

The probability of different manufacturers using the same output format
is near zero. The probability of the same manufacturer using the same
output format twice is pretty slim as well. This situation is what paid
my way though university. ;)



Hamish