[GRASS-dev] GSOC Horizon based stratigraphy

Benjamin Ducke benducke at fastmail.fm
Mon Jun 24 23:53:46 PDT 2013

On 06/25/2013 12:24 AM, Dylan Beaudette wrote:
> On Mon, Jun 24, 2013 at 1:23 PM, Benjamin Ducke <benducke at fastmail.fm
> <mailto: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.

I think you mean Soeren's work. He has contributed what must
be near 90% of the more recent voxel-related work to GRASS.

>         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.

That's exactly what's required. Cheers.

> 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 masks?

I am not sure I understand the meaning of "mask" in this context.
Are we talking about a method to make sure that the interpolation
will not produce voxels in regions where there is no input data?

>     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.

The latter sounds like a good approach.



> Dylan
>     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>
>         <mailto:grass-dev at lists.osgeo.__org
>         <mailto: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 <mailto: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 <mailto:benducke at fastmail.fm>
>     _________________________________________________
>     grass-dev mailing list
>     grass-dev at lists.osgeo.org <mailto: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

More information about the grass-dev mailing list