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@lists.osgeo.org <mailto:grass-dev@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/grass-dev
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
