[GRASS-dev] GSOC Horizon based stratigraphy

Tim Bailey timibly at gmail.com
Mon Jun 24 10:25:11 PDT 2013


Hi Pierre, and Hamish
It is nice to hear about the onset of Winter in New Zealand. Here in
California we are looking at the beginning of a severe season of drought.

Clearly the problem of geographic representation of soil properties are
quite challenging. The US NRCS distributes soil datasets most often as
ArcSDE tables. Not to pander but from my perspective the state of the art
tie in with the nrcs data comes from the recent paper Algorithms for
quantitative pedology: A toolkit for soil scientists Computers &
Geosciences 52 (2013) 258–268. I now realize that you Pierre are a coauthor
of the article. Nice work by the way. In particular the
SoilProfileCollection object specifications are spot on in my opinion. To
paraphrase, the minimal horizon description of unique id, top depth, bottom
depth, linked to attribute any vertical interval attribute data.

I am just a novice with R but it occurs to me that the soilDB and AQP R
modules might be the best way to generate input point vectors.  One
capability that I think is particularly useful is the slicing and
resampling of the vertical profile. For my current purposes, any attributes
of interest from these databases needs to be linked to a point vector as an
intermediary step towards being rendered by voxels.  In the specific case
of categorical data, I am working with the data assumption that the
attributes will be assigned to a point vector located at the bottom of the
interval.

Historically soil inventory profiles have usually been a bit sloppy with
locating elevation absolutely. All of the depth measurements were recorded
in relative terms to the surface.  Would it be possible to deal with high
resolution z coordinates in a manner that was relational in the same way
that soil profiles are collected. The reason I ask is that I worry about
the amount of data required to tile voxels has the potential to grow
inordinately. 10 cm is a pretty rough vertical resolution for soils
purposes, but if you have to populate voxels for a field area that has 100
meters of elevation it could get  overwhelming.  The other route I am
seeing is to create a mask from a digital elevation model to constrain the
region to voxels near the surface elevation. All of the workspaces I am
developing as examples for this project are areas where I have lidar
coverage to pin the depth intervals to a high resolution elevation datum.

Away from soils field I have found some interesting issues in the data
practices. In the geotechnical boreholes the sampling intervals are not
always continuous, and they are specific. Also the reason why I have put in
a line vector in my process is that the vertical assumptions will not
always be met by the data. It occurs to me that a future iteration of this
module is going to want to use dynamic segmentation in order to render data
from boreholes that are not vertical and are only as straight as the the
borehole that is drilled.  Also I hear that horizontal drilling is becoming
a very big deal in the energy sector and I can only imagine that
groundwater prospecting is going to follow.

Also during the project review period Hamish mentioned an interest in
Seismic line interpolation. At the time I worried that a digression into
applied geophysics might be a dangerous distraction but I have subsequently
worked up a workflow for the processing of p-wave first arrivals.  I am
suppressing any thought of any signal that is not a first arrival, but I
think that I can make it work within a day.  I am going to the library this
afternoon to look into this some more.

Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20130624/62944f57/attachment.html>


More information about the grass-dev mailing list