[GRASS-dev] GSOC wk1 checkin

GRASS GIS GRASS GIS developer
1

Tim Bailey
Horizon Based Interpolation module for GRASS
Google Summer of Code Week 1 check in
Friday, June 21 2013

Hi everyone,

During this first week of coding I have been working on input specifications for the horizon descriptions interpolation module. Several early technical challenges emerged. The process for importing horzons turns out to be a bit confounding. Generating input from horizon databases turns out to be non-trivial task. I have done an informal survey of every geologist and soil scientist that I know concerning how they store horizon datasets. In addition I have inspected the storage specifications for several public soils database formats.

In parallel to the programming project I have been building three sandboxes to test the methods developed in this project. One is a site level wetland delineation. Another is a database of geotechnical borehole logs that Bob Moskovitz of the California Geologic Survey provided. The third is a random Natural Resources Conservation Service survey subset.

My work product next week is going to focus on the interpolation module. The abstract workflow for the module as whole is as follows

Process for generation of r3 voxel grid from a population of xy located 1 dimensional horizon descriptions

  1. Import of database horizon descriptions

  2. Generation of line vector representing the path of the horizon description in xyz

  3. Segmentation of the line vector into n number xyz points

  4. query of attribute values to points from attribute database

  5. Generation of r3 region

  6. Interpolation of point attribute values through geostatistical and/or logical operators onto voxel grid locations

After extensive consultation with my programming mentor Ben Ducke, I am now moving on to the interpolation of vector attributes to voxel cells. One point that Ben articulated was that the interpolation assignment needs to be capable of operating on integer data so that it can work on

Best wishes on this first day of summer.

Tim Bailey

2

Hi Tim,

thanks for your report. Just small reminder that this report should be sent in copy also to [soc@lists.osgeo.org](mailto:soc@lists.osgeo.org) ML.

ยทยทยท

Martin

3

Hi Tim, glad to see you're underway.

is it possible to post some data samples on your project's blog? (a description + figure would be great) It would help to get a better idea of what the import options would be for those three datasets. What form is the Natural Resources Conservation Service survey data in?
If you like/need I can poke around here for some more datasets.

My work product next week is going to focus on the interpolation
module. The abstract workflow for the module as whole is as follows

Process for generation of r3 voxel grid from a population of xy
located 1 dimensional horizon descriptions
1. Import of database horizon descriptions
2. Generation of line vector representing the path of the horizon
description in xyz

note that GRASS vector lines can not store per-vertex attribute data,
only per-line attribute data. Anything else must be stored as points;
see the v.in.gps module. one idea is to trick the vector engine into storing depth vs. value1 [vs. value2] in x,y[,z] structure. then translate out the results at the last step when you need real earth-coord x,y,z.
?

3. Segmentation of the line vector into n number xyz points

so binning by depth segment?

4. query of attribute values to points from attribute database
5. Generation of r3 region
6. Interpolation of point attribute values through geostatistical
and/or logical operators onto voxel grid locations

wrt to single x,y location well log, it seems to me like the r3.in.xyz
module already gives you most of that, bypassing the vector line stage
completely. binning 3D data into voxels using univariate statistics is precisely what it does.

are you looking to interpolate/aggregate vertically first, then
horizontally? would you interpolate at each depth band separately
then combine those together?

how well does that work with dipping angles? perhaps v.vol.rst could help too, to interpolate everything at once in a more 3D-influenced model?

One point that Ben articulated was that the interpolation assignment
needs to be capable of operating on integer data so that it can work
on

that got cut off, but I guess you mean categorical value, so nearest
neighbour is needed, and not linear, cubic, or spline.

Best wishes on this first day of summer.

Up to my knees in snow yesterday, but good mountain boots and funner than the rain and sleet that was falling down in the valley. :slight_smile:

regards,
Hamish

4

Hi Tim, Hamish et al.,

Just jumping in the discussion, FYI: I am following the project with
much attention, in particular because I am working with soil data,
both at the national scale in NZ, but also on international project
that aim at storing important amounts of data [www.globalsoilmap.net].

The soil science community has recognised the difficulty to deal with
the storage of soil horizon data, and a specific working group has
been formed under the auspices of the International Union of Soil
Sciences [www.soilinformationstandards.org/content/about].

We've already been developing data models for storing soil data, I'd
be happy to point you towards these if that is of interest for your
project.

Tim, all the best for your summer project,
Hamish, hang on tight for this cold winter blast!

Talk soon,

Pierre

2013/6/23 Hamish <hamish_b@yahoo.com>:

Hi Tim, glad to see you're underway.

is it possible to post some data samples on your project's blog? (a description + figure would be great) It would help to get a better idea of what the import options would be for those three datasets. What form is the Natural Resources Conservation Service survey data in?
If you like/need I can poke around here for some more datasets.

My work product next week is going to focus on the interpolation
module. The abstract workflow for the module as whole is as follows

Process for generation of r3 voxel grid from a population of xy
located 1 dimensional horizon descriptions
1. Import of database horizon descriptions
2. Generation of line vector representing the path of the horizon
description in xyz

note that GRASS vector lines can not store per-vertex attribute data,
only per-line attribute data. Anything else must be stored as points;
see the v.in.gps module. one idea is to trick the vector engine into storing depth vs. value1 [vs. value2] in x,y[,z] structure. then translate out the results at the last step when you need real earth-coord x,y,z.
?

3. Segmentation of the line vector into n number xyz points

so binning by depth segment?

4. query of attribute values to points from attribute database
5. Generation of r3 region
6. Interpolation of point attribute values through geostatistical
  and/or logical operators onto voxel grid locations

wrt to single x,y location well log, it seems to me like the r3.in.xyz
module already gives you most of that, bypassing the vector line stage
completely. binning 3D data into voxels using univariate statistics is precisely what it does.

are you looking to interpolate/aggregate vertically first, then
horizontally? would you interpolate at each depth band separately
then combine those together?

how well does that work with dipping angles? perhaps v.vol.rst could help too, to interpolate everything at once in a more 3D-influenced model?

One point that Ben articulated was that the interpolation assignment
needs to be capable of operating on integer data so that it can work
on

that got cut off, but I guess you mean categorical value, so nearest
neighbour is needed, and not linear, cubic, or spline.

Best wishes on this first day of summer.

Up to my knees in snow yesterday, but good mountain boots and funner than the rain and sleet that was falling down in the valley. :slight_smile:

regards,
Hamish

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Scientist
Landcare Research, New Zealand