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.
Tim
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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
benducke@fastmail.fm
Hi Tim,
i am the second mentor in your SoC project, and will try to help you with the 3D raster approach in GRASS.
···
The 3D raster implementation in GRASS is using a tiled based storage approach.[1]
The tiles can be stored in compressed form (zlib in GRASS7) or uncompressed form on the hard disk. Usually you store them in compressed form. Hence in case you have many tiles that are empty or have equal data, the compression is very high. GRASS can handle 3D raster maps up to hundreds of GB in size. I tested 3D raster maps with about 12 GB in size. The main memory is not an issue when processing 3D raster maps, since only a limited number of tiles is read into main memory at runtime. You can specify the tile size of each 3D raster map that you create. Hence you can adjust it to the needs of the soil depths resolution.
In addition you can specify a 3D raster mask that works pretty the same way as masks in the raster approach in GRASS.
Please don’t bother to ask, if you have any questions about the 3D raster implementation.
Best regards
Soeren
[1] http://grass.osgeo.org/programming7/raster3dlib.html
2013/6/25 Tim Bailey <timibly@gmail.com>
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.
Tim
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On 06/25/2013 10:21 AM, Sören Gebbert wrote:
Hi Tim,
i am the second mentor in your SoC project, and will try to help you
with the 3D raster approach in GRASS.
The 3D raster implementation in GRASS is using a tiled based storage
approach.[1]
The tiles can be stored in compressed form (zlib in GRASS7) or
uncompressed form on the hard disk. Usually you store them in compressed
form. Hence in case you have many tiles that are empty or have equal
data, the compression is very high. GRASS can handle 3D raster maps up
to hundreds of GB in size. I tested 3D raster maps with about 12 GB in
size. The main memory is not an issue when processing 3D raster maps,
since only a limited number of tiles is read into main memory at
runtime. You can specify the tile size of each 3D raster map that you
create. Hence you can adjust it to the needs of the soil depths resolution.
In addition you can specify a 3D raster mask that works pretty the same
way as masks in the raster approach in GRASS.
Simply great! Even after having used GRASS for such a long
time, I keep being amazed by its capabilities.
Please don't bother to ask, if you have any questions about the 3D
raster implementation.
That should read: "Please don't hesitate to ask" -- I am sure 
Best,
Ben
Best regards
Soeren
[1] http://grass.osgeo.org/programming7/raster3dlib.html
2013/6/25 Tim Bailey <timibly@gmail.com <mailto:timibly@gmail.com>>
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.
Tim
_______________________________________________
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
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").
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}.
Just 2 cents,
Pierre
2013/6/25 Benjamin Ducke <benducke@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@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
--
Scientist
Landcare Research, New Zealand
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@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@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
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
benducke@fastmail.fm