On 06/25/2013 12:24 AM, Dylan Beaudette wrote:
On Mon, Jun 24, 2013 at 1:23 PM, Benjamin Ducke <[email protected]
<mailto:[email protected]>> 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.
Best,
Ben
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
[email protected] <mailto:[email protected]>
<mailto:[email protected].__org
<mailto:[email protected]>>
http://lists.osgeo.org/__mailman/listinfo/grass-dev
<http://lists.osgeo.org/mailman/listinfo/grass-dev>
_________________________________________________
grass-dev mailing list
[email protected] <mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
_________________________________________________
grass-dev mailing list
[email protected] <mailto:[email protected]>
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
[email protected]
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
