[GRASS-dev] GSOC Horizons and Stratigraphy

Sören Gebbert soerengebbert at googlemail.com
Tue Jun 25 01:21:07 PDT 2013


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 at 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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20130625/82f9cca6/attachment.html>


More information about the grass-dev mailing list