[GRASS-dev] GSOC Horizons and Stratigraphy

Benjamin Ducke benducke at fastmail.fm
Thu Jun 27 02:40:50 PDT 2013


On 06/26/2013 07:00 PM, Pierre Roudier wrote:
> Hi Benjamin,
>
> As far as soils data, we would probably often mask with depths min or
> max, use a plan to cut the profile collection to return points ("give
> the carbon value at 13.5cm depth for this collection of profiles").
>

Yes, however, please keep in mind that this project
works with soil horizons, i.e. just categories, not
measurable quantities/properties.

Cutting through the interpolated voxel model to get a
2D distribution of horizons can easily be done with
the existing GRASS tools.

> Alternatively, we would try to interpolate a profile collection to
> harmonise soil depths: while data is usually collected on
> heterogeneous depths intervals, one might want to harmonise the
> collection for quantitative analysis: for example the new depth
> support might be {0-5cm, 5-10cm, 10-30 cm, 30-60cm, 60-100cm}.
>

That should be possible by retrieving new cross-sections
from the interpolated voxel model.

Best,

Ben

> Just 2 cents,
>
> Pierre
>
>
> 2013/6/25 Benjamin Ducke <benducke at fastmail.fm>:
>> On 06/25/2013 10:00 AM, Tim Bailey wrote:
>>>
>>>
>>>
>>> Hi Ben,
>>>
>>> All that I meant by mask is, in this case,  an r3 map that defines a
>>> subset of space that subsequent operations are constrained to. I guess I
>>> was just expressing worry about creating runaway data demands.The region
>>> settings act as a three dimensional bounding cube, does not seem
>>> adequate to constrain a tiling scheme with relatively sparse data.In the
>>> compromise scenario that Dylan suggested with 10 meter xy and 1 cm z
>>> resolution and 1 meter depth we would be looking at populating 10000
>>> voxels per hectare for a flat landscape. However if we were using a
>>> simple bounding box to define the region and we had 5 meters of relief
>>> we would end up with 50000 or 60000 voxels. As the area of coverage gets
>>> bigger cost of the range in z values gets worse.
>>>
>>
>> That's a good point that I hadn't thought about.
>> Clearly, we don't want the interpolation to go
>> beyond the limits of the terrain surface. It would
>> probably be a good idea for the user to be able to
>> supply an additional DEM input that could supply
>> upper cut-off values. A lower cut-off could simply
>> be defined as a constant depth value, and the same
>> for the extents along the X-Y plane. Apart from that,
>> the interpolator should use a configurable search
>> radius for points, so that it won't start interpolating
>> values in areas that have no sample data.
>>
>> Ben
>>
>>> Tim
>>>
>>>
>>> _______________________________________________
>>> grass-dev mailing list
>>> grass-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>>
>>
>>
>>
>> --
>> Dr. Benjamin Ducke, M.A.
>> {*} Geospatial Consultant
>> {*} GIS Developer
>>
>>    benducke at fastmail.fm
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev at lists.osgeo.org
>> 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