[GRASSLIST:3559] Re: Geophysical framework: WHITE PAPER
benducke at compuserve.de
benducke at compuserve.de
Tue Jun 1 06:57:24 EDT 2004
Michael,
thanks
for
all
the
comments.
After
some
hard
thinking,
I
came
to
the
conclusion,
that
your
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
-----
Originalnachricht
-----
Von:
Michael
Barton
<michael.barton at asu.edu>
Datum:
Dienstag,
1.
Juni
2004
6:39
am
Betreff:
[GRASSLIST:3558]
Geophysical
framework:
WHITE
PAPER
>
Benjamin,
>
>
Your
white
paper
clearly
represents
considerable
thought
into
the
>
needs
>
for
processing
geophysical
survey
data.
This
is
a
good
beginning
>
for
>
looking
at
GRASS
from
a
geophysical
survey
perspective.
I
think
it
>
is
>
great
that
you
are
serious
about
pursuing
this
and
enhancing
GRASS
>
for
>
this
aspect
of
archaeological
and
geological
research.
The
value
of
>
using
GRASS
as
a
platform
for
processing
geophysical
data
is
that
>
it
>
provides
a
rich
and
complex
tool
set
for
the
analysis
and
>
management
of
>
spatial
data.
However,
this
richness
comes
at
the
price
of
a
rather
>
steep
learning
curve
(though
not
any
steeper
than
other
full-
>
featured
>
GIS
systems).
Because
you
are
at
the
early
stages
of
learning
>
GRASS,
I
>
hope
to
help
by
offering
ideas
about
how
to
best
use
the
existing
>
tools
>
in
GRASS
to
further
this
objective.
>
>
First,
I
want
to
be
sure
that
I
understand
the
overarching
>
objectives
>
of
such
work.
Please,
Benjamin
and
anyone,
feel
free
to
offer
>
amendments
or
corrections
here.
As
I
see
it...
>
>
1.
Geophysical
equipment
in
the
field
record
data
at
a
series
of
>
points
>
within
a
survey
area.
These
points
theoretically
sample
a
>
continuous
>
field
of
some
parameter
(earth's
magnetic
field,
soil
conductivity,
>
radar
reflections,
etc.).
Usually
values
are
recorded
at
some
set
>
'depth'
below
the
surface
(or
depth
range)
for
all
points
in
a
>
given
>
survey.
But
in
some
cases,
GPR
or
electromagnetic
tomography
for
>
example,
values
may
be
recorded
for
multiple
depths
at
each
sample
>
point.
>
>
2.
A
model
of
the
continuous
field
must
be
constructed
from
the
>
sample
>
points.
Usually,
this
model
takes
on
the
format
of
a
continuous
>
surface
>
and
is
digitally
represented
by
a
regular
grid
that
is
conceptually
>
equivalent
to
a
digital
elevation
model
(i.e.,
a
raster
grid
of
>
equal-sized
square
cells,
in
which
each
cell
has
a
value
of
the
>
field
>
at
that
point).
>
>
3.
This
field
model--or
surface--needs
to
be
transformed
to
enhance
>
specific
signals
of
potential
interest.
This
transformation
>
commonly
>
involves
moving
window
convolving
filters,
fast
fourier
(for
>
destriping)
transformations,
and
whole
image
transformations
(e.g.,
>
contrast
enhancement
or
gamma
correction,
Laplacian
edge
detection,
>
etc.).
>
>
4.
The
transformed
field
model
needs
to
be
georeferenced
so
that
it
>
can
>
be
integrated
with
field
models
from
other
geophysical
surveys
and
>
different
types
of
archaeological
or
geological
data.
>
>
Given
these
objectives,
I
offer
some
suggestions
as
to
how
to
>
integrate
>
existing
GRASS
modules
with
some
of
the
new
ones
you
are
>
proposing.
>
I'm
attaching
a
text
file
with
these
suggestions
so
as
not
to
make
>
the
>
text
in
this
email
overly
long.
>
>
Cheers
>
Michael
Barton
>
>
-------------- next part --------------
____________________
C. Michael Barton, Professor
School of Human Origins, Cultures, & Societies
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA
Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>
On May 29, 2004, at 10:01 PM, Multiple recipients of list wrote:
> as promised, this is the white paper in which I attempt to
> outline a unified framework for implementing geophysical
> functionality in GRASS.
>
> What is missing:
>
> - anything relating to 3D analysis
> - color ramp modification tools
> - a full list of the actual filter functionality we want to
> implement (see section at bottom of document),
> should also include a short description of how each filter
> operates and what it is useful for
>
>
> I am attaching a PDF version for viewing and a M$Word version
> for your edits.
> I would like everyone interested to add comments, make changes
> and additions, look for inconsistencies (terminology), spelling,
> grammar (I am not a native English speaker), clarifications
> - please mark your changes with another colour in the DOC file
> and send it back to me, so I can synchronise all the edits.
> Craig would then be able to forward the white paper for review.
More information about the grass-user
mailing list