[GRASS-dev] GSOC Horizon based stratigraphy

GRASS GIS GRASS GIS developer
1

Hi Pierre, and Hamish

It is nice to hear about the onset of Winter in New Zealand. Here in California we are looking at the beginning of a severe season of drought.

Clearly the problem of geographic representation of soil properties are quite challenging. The US NRCS distributes soil datasets most often as ArcSDE tables. Not to pander but from my perspective the state of the art tie in with the nrcs data comes from the recent paper Algorithms for quantitative pedology: A toolkit for soil scientists Computers & Geosciences 52 (2013) 258–268. I now realize that you Pierre are a coauthor of the article. Nice work by the way. In particular the SoilProfileCollection object specifications are spot on in my opinion. To paraphrase, the minimal horizon description of unique id, top depth, bottom depth, linked to attribute any vertical interval attribute data.

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.

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.

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

2

On Mon, Jun 24, 2013 at 10:25 AM, Tim Bailey <timibly@gmail.com> wrote:

Hi Pierre, and Hamish
It is nice to hear about the onset of Winter in New Zealand. Here in
California we are looking at the beginning of a severe season of drought.

Hi Tim, nice to see another person from CA on the grass-dev list!

Clearly the problem of geographic representation of soil properties are
quite challenging. The US NRCS distributes soil datasets most often as
ArcSDE tables. Not to pander but from my perspective the state of the art
tie in with the nrcs data comes from the recent paper Algorithms for
quantitative pedology: A toolkit for soil scientists Computers &
Geosciences 52 (2013) 258–268. I now realize that you Pierre are a
coauthor of the article. Nice work by the way. In particular the
SoilProfileCollection object specifications are spot on in my opinion. To
paraphrase, the minimal horizon description of unique id, top depth, bottom
depth, linked to attribute any vertical interval attribute data.

Totally agree, the NRCS has not done a good job of releasing data in open
formats. I am working on changing that, but it might take a while. Efforts
like this SoC project are one more way in which soils/geologic data can be
opened to a larger audience. Glad to hear you liked the Comp & and GeoSci.
article, please do comment/critique as issues arise.

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.

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.

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
http://lists.osgeo.org/mailman/listinfo/grass-dev

3

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

   benducke@fastmail.fm

4

On Mon, Jun 24, 2013 at 1:23 PM, Benjamin Ducke <benducke@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.

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!

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@lists.osgeo.org mailto:[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

benducke@fastmail.fm

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

5

On 06/25/2013 12:24 AM, Dylan Beaudette wrote:

On Mon, Jun 24, 2013 at 1:23 PM, Benjamin Ducke <benducke@fastmail.fm
<mailto:benducke@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@lists.osgeo.org <mailto:grass-dev@lists.osgeo.org>
        <mailto:grass-dev@lists.osgeo.__org
        <mailto:grass-dev@lists.osgeo.org>>
        http://lists.osgeo.org/__mailman/listinfo/grass-dev
        <http://lists.osgeo.org/mailman/listinfo/grass-dev&gt;

        _________________________________________________
        grass-dev mailing list
        grass-dev@lists.osgeo.org <mailto:grass-dev@lists.osgeo.org>
        http://lists.osgeo.org/__mailman/listinfo/grass-dev
        <http://lists.osgeo.org/mailman/listinfo/grass-dev&gt;

    --
    Dr. Benjamin Ducke, M.A.
    {*} Geospatial Consultant
    {*} GIS Developer

    benducke@fastmail.fm <mailto:benducke@fastmail.fm>

    _________________________________________________
    grass-dev mailing list
    grass-dev@lists.osgeo.org <mailto:grass-dev@lists.osgeo.org>
    http://lists.osgeo.org/__mailman/listinfo/grass-dev
    <http://lists.osgeo.org/mailman/listinfo/grass-dev&gt;

--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

   benducke@fastmail.fm

6

Hi all,

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.

+1 - I think a native GRASS implementation would make a lot of sense.

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.

That's the very nature of soils data - we soil scientists often deal
with pixels of 10 to 500m resolution, to observe processes that occur
generally in the first meter in the z axis! It is not a problem, and
the challenge is to come up with tools that allow us to store, query
and interpolate such 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 mass-preserving splines has become a key tool in the GlobalSoilMap
project. An implementation in R exists but is not very efficient. This
could be an opportunity to come up with a reference implementation! As
mentioned by Dylan, various interpolation methods are available,
restricted cubic splines look good as well.

Cheers,

P

7

On 06/26/2013 06:48 PM, Pierre Roudier wrote:

Hi all,

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.

+1 - I think a native GRASS implementation would make a lot of sense.

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.

That's the very nature of soils data - we soil scientists often deal
with pixels of 10 to 500m resolution, to observe processes that occur
generally in the first meter in the z axis! It is not a problem, and
the challenge is to come up with tools that allow us to store, query
and interpolate such 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 mass-preserving splines has become a key tool in the GlobalSoilMap
project. An implementation in R exists but is not very efficient. This
could be an opportunity to come up with a reference implementation! As
mentioned by Dylan, various interpolation methods are available,
restricted cubic splines look good as well.

But is that method suitable for categorized input data?
Or does it only work for continuous soil properties?
A spline-based interpolator from 3D vector to 3D raster
already exists in GRASS (v.vol.rst).

Best,

Ben

Cheers,

P

--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

   benducke@fastmail.fm

8

Hi Ben,

You are right, these mass-preserving splines are for continuous data -
it seems I have been carried away from the original scope of the
project while writing my email :slight_smile:

Cheers,

P

2013/6/27 Benjamin Ducke <benducke@fastmail.fm>:

On 06/26/2013 06:48 PM, Pierre Roudier wrote:

Hi all,

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.

+1 - I think a native GRASS implementation would make a lot of sense.

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.

That's the very nature of soils data - we soil scientists often deal
with pixels of 10 to 500m resolution, to observe processes that occur
generally in the first meter in the z axis! It is not a problem, and
the challenge is to come up with tools that allow us to store, query
and interpolate such 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 mass-preserving splines has become a key tool in the GlobalSoilMap
project. An implementation in R exists but is not very efficient. This
could be an opportunity to come up with a reference implementation! As
mentioned by Dylan, various interpolation methods are available,
restricted cubic splines look good as well.

But is that method suitable for categorized input data?
Or does it only work for continuous soil properties?
A spline-based interpolator from 3D vector to 3D raster
already exists in GRASS (v.vol.rst).

Best,

Ben

Cheers,

P

--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  benducke@fastmail.fm
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Scientist
Landcare Research, New Zealand