[GRASS-dev] GSOC Horizon based stratigraphy

[Benjamin Ducke]

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

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

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.

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



-- 
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

   benducke at fastmail.fm