[GRASSLIST:3562] Re: Geophysical framework: WHITE PAPER, ungarbled message

[Benjamin Ducke]

NOTE: The last message I sent got garbled up,
so please disregard and read this one instead:


Michael, thanks for all the comments.

After some hard thinking, I came to the conclusion,
that yout idea about importing raw data into a vector file is
indeed preferable.
One thing we have to be aware of is, that there
are two distinct modes of data in a geophysical survey:

(a) continuous (gradiometer, caesiometer):
1.2  1.4  0.7  4.5
3.4  4.5  0.6  0.9
2.3  4.7  3.4  1.7
...


(b) scattered (could be anything, point measurements with locations):
10m  15m  1.7
8 m  12m  1.3
11m  7 m  0.9
...


(a) can very easily be converted to (b) by adding coordinates, so it would
indeed be easy to have a unified data model.

For data type (a), rasterisation can be done without interpolation and the
filters should be run on this, un-interpolated, data.
Interpolation will only be necessary in the final step, if the axes and/or
resolution of the working location are different than those of the data.
So -- just one interpolation in this case.

For type (b), interpolation will have to be done right after import, because
** I think ** filters will work better on data which is still properly aligned
to the region's X/Y axes. I have a hard time, e.g. imagining a destripe filter
work well on stripes running diagonally, which might happen,
if the filter is to run on a rectified image (correct me, if this is wrong!).
In this case, we would indeed need two interpolations for the final result.

I would like to keep the grid layout information intact, because I deem
it very handy.

I would then envision the workflow as such:


1. Import all raw data files as vector files (module v.grid in instead of r.grid.in)
	- create coordinates (using grid layout's origin and resolution) for 
	  scattered measurement data
	- remember the data mode of the grid: either 'scattered' or 'continuous'
	- keep the grid structure the way it was laid out in the field, by adding
	  an attribute to each vector point which represents the grid it belongs to
	- have all measurements of a grid layout in one file -- no need for separate
	  elements any longer	  
	- upon import, check the 'grid_no' attribute, to see if data has already
	  been imported for this grid. If so:
	  	- check every point in the grid and update, if necessary OR
		- delete all prior points and replace with new ones
	- this way, professional users can have arbitrarily shaped grid layouts,
	  by specfying a 1x1 dimension and using non-continuous measurements.
	  Also, the handy grid layout will be kept intact
	  
2. Rasterisation and filtering
	- on-the-fly rasterisation into a .tmp raster file, using the grid layout's
	  orthogonal system and resolution:
	  	- if mode of data was 'continuous', do a one 1:1 rasterisation
		- if mode was 'scattered', use splines or whatever to create interpolated raster
	- perform filtering on non-rectified raster (important for math stuff to work, I think!)
	- rectify raster and copy the result as a regular file to the user's working
	  location. Also do interpolation of continous data, if user desires it (otherwise,
	  just let GRASS stretch or shrink it to the current region's resolution)
	
	
All of the remaining infrastructure could be kept intact.
We would use as much existing functionality, as possible.
I think, a separate database element 'grid_layout' would still
make sense to store information, such as grid layout dimensions,
control points for rectification, data mode. Same for the filter list.
Or is there a better way to store such information in the vector file itself?

Terminology in the white paper definitely needs a clean-up job.
Let's settle on using the term 'grid' for the things we actually
lay out in the field. A grid layout would then be the representation
of these grids' arrangements in GRASS.

'r.composite' will have to be renamed. Suggestions, anyone?


Cheers,

Benjamin