[GRASS-dev] GSOC Horizon based stratigraphy

Dylan Beaudette dylan.beaudette at gmail.com
Mon Jun 24 15:24:14 PDT 2013

On Mon, Jun 24, 2013 at 1:23 PM, Benjamin Ducke <benducke at fastmail.fm>wrote:

> Hi All,
> First of all, I am very excited to see how much interest this
> project is getting, and it is great that Tim has already got the
> support of so many soil science professionals. This will ensure
> that the results of his work will be suitable for real-world use.
> <snip>
Thank you Ben for sponsoring this effort. I have tinkered with your r3*
code over the last couple of years, and have always wanted to integrate it
into my soil survey work and associated research.

>> Hi Tim, nice to see another person from CA on the grass-dev list!
>>  <snip>
>>     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.
> No doubt, those R classes are very elegant. However, Tim, introducing
> R as a dependency into your project will put an additional burden
> on you that you should carefully weigh against your time budget.
> I think you should consider soil data representation and soil data
> interpolation as two separate problems and work on the interpolation
> bit first, as that is the core of your GSoC project description.
> I realize that this discussion is both interesting and important.
> But I also think that Tim should put priority on synthesizing a usable
> 3D sample dataset  first, so that he can implement a first version of
> the interpolation algorithm.
> Once he starts designing the algorithm, he will probably
> find that it has certain requirements on the input data that are
> not always met by typical soil science datasets. When he is clear
> about them, he will also have a much better idea of what can and
> cannot be done with typical soil science data (and geological cores,
> etc.).
This is an excellent point. While I like the mention of AQP in this
context, I totally support a GRASS-based implementation with as few
dependencies as possible. Once progress has been made on the algorithm then
we can tinker with I/O. Pierre and I will likely be happy to contribute
ideas and code for going between the SoilProfileCollection and whatever Tim
implements. That would be a good time as well to contribute some code for
exporting SoilProfileCollection objects into something that the current
r3.* modules can understand.

I don't have any geologic data sets, however, I have several soils data
sets that may be of general interest for algorithm development and testing.
Let me know when you are ready for those. I can imagine some fairly
interesting demos on the horizon (ha, soils-pun!) related to the conversion
of existing soil survey (polygons) into waffle-voxels.

>      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.
> Yes, the thought of such "waffel voxels" is not exactly appealing.
> However, they may be a smaller problem in practice, since the voxel
> models themselves are often used to derive vertical slices
> ("profiles"), and those might look perfectly fine, even if derived
> from malformed voxels. GRASS does allow for individual X, Y and Z
> dimensions of voxels, so there is no technical problem with this.
> The results of the interpolation don't need to be beautiful, they
> just need to be as accurate and as true to the data as possible.
Excellent. What kind of tools do we have for implementing reasonable voxel

> Also take into account that the difference in horizontal and vertical
> resolution may well reflect a fact of nature! Where soil layers tend to
> spread out horizontally, the data will have more variation along
> the vertical. You will need to take this into account when designing the
> interpolation algorithm. It will probably have to be based on some sort
> of nearest neighbor method (as Hamish suggested earlier) and thus
> "nearest" must be weighted differently in the vertical than in the
> horizontal dimension. The weightings should probably be figured out
> from the input data.
This is a popular topic in the soils literature-- vertical anisotropy can
be an order of magnitude greater than what is found in the horizontal.
Restricted cubic splines have some desirable characteristics for dealing
with this kind of data-- however, these work best in the context of a
regression model. Also, there are the mass-preserving splines that are more
useful in the "interpolation along the soil profile" sense. For categorical
data, I would recommend the ordinal-ratio logistic regression model, which
generates class-wise probability estimates. I have found this quite useful
for generating probability depth-functions for categorical soil properties.
I can elaborate as needed.


> Ben
>>     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.
>> Cheers,
>> Dylan
>> PS: I have cc-ed my "work" email address, as I don't always check my
>> gmail account.
>>     ______________________________**_________________
>>     grass-dev mailing list
>>     grass-dev at lists.osgeo.org <mailto:grass-dev at lists.osgeo.**org<grass-dev at lists.osgeo.org>
>> >
>>     http://lists.osgeo.org/**mailman/listinfo/grass-dev<http://lists.osgeo.org/mailman/listinfo/grass-dev>
>> ______________________________**_________________
>> grass-dev mailing list
>> grass-dev at lists.osgeo.org
>> http://lists.osgeo.org/**mailman/listinfo/grass-dev<http://lists.osgeo.org/mailman/listinfo/grass-dev>
> --
> Dr. Benjamin Ducke, M.A.
> {*} Geospatial Consultant
> {*} GIS Developer
>   benducke at fastmail.fm
> ______________________________**_________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/**mailman/listinfo/grass-dev<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/af8a4749/attachment.html>

More information about the grass-dev mailing list