[GRASS-dev] GSOC Horizon based stratigraphy
Benjamin Ducke
benducke at fastmail.fm
Mon Jun 24 23:53:46 PDT 2013
On 06/25/2013 12:24 AM, Dylan Beaudette wrote:
> On Mon, Jun 24, 2013 at 1:23 PM, Benjamin Ducke <benducke at fastmail.fm
> <mailto: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.
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
> grass-dev at lists.osgeo.org <mailto:grass-dev at lists.osgeo.org>
> <mailto:grass-dev at lists.osgeo.__org
> <mailto: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 <mailto: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 <mailto:benducke at fastmail.fm>
>
> _________________________________________________
> 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
> <http://lists.osgeo.org/mailman/listinfo/grass-dev>
>
>
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
benducke at fastmail.fm
More information about the grass-dev
mailing list