On Mon, Jun 24, 2013 at 1:23 PM, Benjamin Ducke <span dir="ltr"><<a href="mailto:benducke@fastmail.fm" target="_blank">benducke@fastmail.fm</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi All,<br>
<br>
First of all, I am very excited to see how much interest this<br>
project is getting, and it is great that Tim has already got the<br>
support of so many soil science professionals. This will ensure<br>
that the results of his work will be suitable for real-world use.<br>
<br>
<snip><div class="im"><br></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Hi Tim, nice to see another person from CA on the grass-dev list!<br>
<br>
</blockquote></div>
<snip><div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I am just a novice with R but it occurs to me that the soilDB and<br>
AQP R modules might be the best way to generate input point<br>
vectors. One capability that I think is particularly useful is the<br>
slicing and resampling of the vertical profile. For my current<br>
purposes, any attributes of interest from these databases needs to<br>
be linked to a point vector as an intermediary step towards being<br>
rendered by voxels. In the specific case of categorical data, I am<br>
working with the data assumption that the attributes will be<br>
assigned to a point vector located at the bottom of the interval.<br>
<br>
</blockquote>
<br></div>
No doubt, those R classes are very elegant. However, Tim, introducing<br>
R as a dependency into your project will put an additional burden<br>
on you that you should carefully weigh against your time budget.<br>
I think you should consider soil data representation and soil data<br>
interpolation as two separate problems and work on the interpolation<br>
bit first, as that is the core of your GSoC project description.<br>
<br>
I realize that this discussion is both interesting and important.<br>
But I also think that Tim should put priority on synthesizing a usable<br>
3D sample dataset first, so that he can implement a first version of<br>
the interpolation algorithm.<br>
<br>
Once he starts designing the algorithm, he will probably<br>
find that it has certain requirements on the input data that are<br>
not always met by typical soil science datasets. When he is clear<br>
about them, he will also have a much better idea of what can and<br>
cannot be done with typical soil science data (and geological cores,<br>
etc.).<div class="im"><br>
<br></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Historically soil inventory profiles have usually been a bit sloppy<br>
with locating elevation absolutely. All of the depth measurements<br>
were recorded in relative terms to the surface. Would it be<br>
possible to deal with high resolution z coordinates in a manner that<br>
was relational in the same way that soil profiles are collected. The<br>
reason I ask is that I worry about the amount of data required to<br>
tile voxels has the potential to grow inordinately. 10 cm is a<br>
pretty rough vertical resolution for soils purposes, but if you have<br>
to populate voxels for a field area that has 100 meters of elevation<br>
it could get overwhelming. The other route I am seeing is to<br>
create a mask from a digital elevation model to constrain the region<br>
to voxels near the surface elevation. All of the workspaces I am<br>
developing as examples for this project are areas where I have lidar<br>
coverage to pin the depth intervals to a high resolution elevation<br>
datum.<br>
<br>
<br>
I have often wondered about the scale issue you bring up. 1cm precision<br>
in the vertical vs. 10m precision in the horizontal is often a good<br>
compromise for soils/landscapes in the western US. This would result in<br>
some pretty funny looking voxels-- more like waffles. A decent mask and<br>
tools for rapid development of a mask would be essential.<br>
</blockquote>
<br></div>
Yes, the thought of such "waffel voxels" is not exactly appealing.<br>
However, they may be a smaller problem in practice, since the voxel<br>
models themselves are often used to derive vertical slices<br>
("profiles"), and those might look perfectly fine, even if derived<br>
from malformed voxels. GRASS does allow for individual X, Y and Z<br>
dimensions of voxels, so there is no technical problem with this.<br>
The results of the interpolation don't need to be beautiful, they<br>
just need to be as accurate and as true to the data as possible.<br>
<br></blockquote><div><br></div><div>Excellent. What kind of tools do we have for implementing reasonable voxel masks?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also take into account that the difference in horizontal and vertical<br>
resolution may well reflect a fact of nature! Where soil layers tend to<br>
spread out horizontally, the data will have more variation along<br>
the vertical. You will need to take this into account when designing the<br>
interpolation algorithm. It will probably have to be based on some sort<br>
of nearest neighbor method (as Hamish suggested earlier) and thus<br>
"nearest" must be weighted differently in the vertical than in the<br>
horizontal dimension. The weightings should probably be figured out<br>
from the input data.<br>
<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Dylan</div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ben<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<br>
Away from soils field I have found some interesting issues in the<br>
data practices. In the geotechnical boreholes the sampling intervals<br>
are not always continuous, and they are specific. Also the reason<br>
why I have put in a line vector in my process is that the vertical<br>
assumptions will not always be met by the data. It occurs to me that<br>
a future iteration of this module is going to want to use dynamic<br>
segmentation in order to render data from boreholes that are not<br>
vertical and are only as straight as the the borehole that is<br>
drilled. Also I hear that horizontal drilling is becoming a very<br>
big deal in the energy sector and I can only imagine that<br>
groundwater prospecting is going to follow.<br>
<br>
Also during the project review period Hamish mentioned an interest<br>
in Seismic line interpolation. At the time I worried that a<br>
digression into applied geophysics might be a dangerous distraction<br>
but I have subsequently worked up a workflow for the processing of<br>
p-wave first arrivals. I am suppressing any thought of any signal<br>
that is not a first arrival, but I think that I can make it work<br>
within a day. I am going to the library this afternoon to look into<br>
this some more.<br>
<br>
Tim<br>
<br>
<br>
Again, glad to see someone working on this issue and always happy to<br>
offer insight from the soils/NRCS perspective.<br>
<br>
Cheers,<br>
Dylan<br>
<br>
PS: I have cc-ed my "work" email address, as I don't always check my<br>
gmail account.<br>
<br>
______________________________<u></u>_________________<br>
grass-dev mailing list<br></div></div>
<a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a> <mailto:<a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.<u></u>org</a>><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">http://lists.osgeo.org/<u></u>mailman/listinfo/grass-dev</a><div class="im"><br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">http://lists.osgeo.org/<u></u>mailman/listinfo/grass-dev</a><br>
<br>
</div></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<br>
<br>
-- <br>
Dr. Benjamin Ducke, M.A.<br>
{*} Geospatial Consultant<br>
{*} GIS Developer<br>
<br>
<a href="mailto:benducke@fastmail.fm" target="_blank">benducke@fastmail.fm</a></font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">http://lists.osgeo.org/<u></u>mailman/listinfo/grass-dev</a><br>
</div></div></blockquote></div><br>