[GRASS-dev] GSOC Horizon based stratigraphy

Dylan Beaudette dylan.beaudette at gmail.com
Mon Jun 24 11:38:21 PDT 2013

On Mon, Jun 24, 2013 at 10:25 AM, Tim Bailey <timibly at gmail.com> wrote:

> 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.
Hi Tim, nice to see another person from CA on the grass-dev list!

> 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.
Totally agree, the NRCS has not done a good job of releasing data in open
formats. I am working on changing that, but it might take a while. Efforts
like this SoC project are one more way in which soils/geologic data can be
opened to a larger audience. Glad to hear you liked the Comp & and GeoSci.
article, please do comment/critique as issues arise.

> 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.
I have often wondered about the scale issue you bring up. 1cm precision in
the vertical vs. 10m precision in the horizontal is often a good compromise
for soils/landscapes in the western US. This would result in some pretty
funny looking voxels-- more like waffles. A decent mask and tools for rapid
development of a mask would be essential.

> 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
Again, glad to see someone working on this issue and always happy to offer
insight from the soils/NRCS perspective.


PS: I have cc-ed my "work" email address, as I don't always check my gmail

> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20130624/97bdf128/attachment-0001.html>

More information about the grass-dev mailing list