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