[GRASS-dev] New raster-to-raster3d conversion module
Helena Mitasova
hmitaso at unity.ncsu.edu
Fri Jul 14 12:53:15 EDT 2006
I don't know whether this is important or not, but at CERL the length
of command names
was carefully guarded (I was not allowed s.surf.tps.cv), so I am
wondering whether we
should continue this tradition and keep just two dots in the name for
as long as possible -
maybe it is possible to find a meaningful two dots name for
r.elev.to.rast3?
If not - should we set some rules on how to create names for new
modules and when
more dots should be used? The concern then was that it will get out
of control and soon we will
have ever longer and messier names.
Helena
On Jul 10, 2006, at 6:52 PM, Soeren Gebbert wrote:
> Dear Benjamin and devs,
>
> On Monday 10 July 2006 17:07, Benjamin Ducke wrote:
>> Soeren,
>>
>> that sounds cool.
>> However, I am to dumb to understand just exactly what the module
>> does from the screenshot you provided.
>> Could you elaborate?
>
> I will try, but my "d"english is horrible.
>
> With r.elev.to.rast3 you can put raster map values from a specific
> map (input)
> in a specific elevation layer within a g3d volume, based on a 2D
> elevation map (elev).
> Every 3D cell of the volume that intersect with the elevation map
> will be set to the cell value of the input map.
> If the hight value of the elevation map is exactly located at the
> border between two 3D cells, both cells
> will get the input map value.
>
> This works perfectly for putting geological strata into g3d
> volumes. I need this for modelling
> a 3D aquifer.
>
> The screenshot
> http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/
> r.elev.to.rast3.png
> shows 3 options how to put raster map values into a g3d map.
>
> Here are the options of r.elev.to.rast3:
>
> Description:
> Creates a 3D volume map based on a 2D elevation and value raster map
>
> Usage:
> r.elev.to.rast3 [-ul] input=string elev=string output=string
> [upper=value] [lower=value] [--overwrite]
>
> Flags:
> -u Use the input map values to fill the upper cells
> -l Use the input map values to fill the lower cells
> --o Force overwrite of output files
>
> Parameters:
> input 2d raster maps which represent the values
> elev 2d raster maps which represent the elevation
> output output 3dcell map
> upper The value to fill the upper cells, default is null
> lower The value to fill the lower cells, default is null
>
>
> In the upper volume of the screenshot the 3D elevation layer based
> on the grey cutplane
> on the left was filled with the data from the (colored) 2D input
> map. Also all
> the 3D cells above the elevation layer are filled with the values
> from the input map.
>
> In the middle volume only the elevation layer was filled with the
> input map values, upper
> and lower 3D cells are not filled (null).
>
> In the lower volume the elevation layer and all 3D cells lower than
> the elevation layer are filled
> with the input map values.
>
>> 3D functionality in GRASS is really getting somewhere.
>> The only things I could wish for:
>>
>> 1. Make volume vizualization work in NVIZ
>
> Well, it works for isosurfaces and cutplanes. But i dont know how
> to implement real
> volume rendering. (have no clue of OpenGL)
> For this reason i implemented the r/r3/v.out.vtk export modules to
> visualize all
> the grass data with VTK based programs like Paraview or MayaVi.
> And VTK provides much more visualisation capabilities you can
> imagine. We will never have
> the manpower to implement this into nviz.
>
> btw.:
> VTK provides Python bindings. Thus with grass swig/Python support
> and the VTK Python bindings,
> direct data interaction/visualisation can be implemented. Hm, maybe
> i should learn Python .... .
>
>> 2. Module to convert 3D Polygon -> 3D raster map
>
> You will need something like a volume rasterizer to do this. That
> is not easy to implement.
> And the hardest thing of 3D polygons with more than 4 vertices is,
> that the polygon surface is not
> well defined. You will need additonal points for triangulation.
> Otherwise you dont get the surface you expect.
> Only triangles or quadrangles are well suited for rasterisation.
>
> But r.elev.to.rast3 provides limited potentialities for this.
> You can convert lines, boundaries or areas into raster maps and put
> them with r.to.rast3 or r.elev.to.rast3,
> into a g3d volume.
>
>> 3. Module to query 3d raster value using 3D vector points/coordinates
>
> You can do this with Paraview. VTK will give you the options to
> combine/intersect
> pointdata, polydata or unstructured grid data with any kind of
> volume data.
> Paraview will give you the data on specific points or a specific
> path within the volume.
> You can use threshold filter, grid filter, cutplanes and much more
> to discover your 3D data.
>
>> 4. Categorization and information like r.report provides
>
> I was thinking today about a module like r.stats -> r3.stats. But
> i'm just thinking about it. ;)
>
>>
>> Maybe for GRASS 6.2?
>
> You are welcome to help implementing this. :)
>
> Best regards
> Soeren
>
> btw.:
> r.elev.to.rast3 is in CVS now. But it will not build by default,
> the entry in the Makefile
> is "missing".
> A new grass test suite with r.elev.to.rast3 tests is available
> (version 0.2.0.9):
> http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/
> GRASS_Testsuite-0.2.0.9.tar.bz2
>
>>
>> Thanks,
>>
>> Benjamin.
>>
>> Soeren Gebbert wrote:
>>> Dear Hamish,
>>>
>>> On Monday 10 July 2006 02:53, Hamish wrote:
>>>
>>>> Soeren Gebbert wrote:
>>>>
>>>>> i would like to add a new raster-to-raster3d conversion module
>>>>> to the grass6.1 CVS in the near future.
>>>>>
>>>>> The module is called r.elev.to.rast3.
>>>>> It creates a new 3D raster map from a 2D elevation and a
>>>>> 2D "value" raster map. The principal functioning is shown here:
>>>>> http://www-pool.math.tu-berlin.de/~soeren/grass/modules/
>>>>> screenshots/r.elev.to.rast3.png
>>>>
>>>> Congratulations on the new module!
>>>
>>>
>>> Many thanks!
>>>
>>>
>>>>> I would like to ask if i can commit this module next week, or if i
>>>>> have to wait until GRASS 6.1.0 is released?
>>>>> I have tested this module with different datasets and it seems
>>>>> to work
>>>>> properly. And i will add some tests to the grass test-suite.
>>>>
>>>>
>>>> If the new module is ready to be in CVS, but you are not sure if
>>>> it is
>>>> release-ready, you can always put it in CVS but not add it to the
>>>> Makefile or GUI menus. (as long as the change doesn't touch
>>>> other parts
>>>> of the software)
>>>
>>>
>>> Ok, i will submit it after some more testing, but will not add it
>>> to the Makefile/GUI.
>>>
>>>
>>>>> I think together with r.to.rast3
>>>>> http://www-pool.math.tu-berlin.de/~soeren/grass/modules/
>>>>> screenshots/r.to.rast3.png
>>>>> r3.to.rast
>>>>> http://www-pool.math.tu-berlin.de/~soeren/grass/modules/
>>>>> screenshots/r3.to.rast.png
>>>>> and r3.cross.rast
>>>>> http://www-pool.math.tu-berlin.de/~soeren/grass/modules/
>>>>> screenshots/r3.cross.rast.png
>>>>> the raster<->rast3d modelling/conversion capabilities are mostly
>>>>> complete.
>>>>
>>>>
>>>> Small versions of those pics would be a great addition to the help
>>>> pages, see r.terraflow, v.voronoi for examples.
>>>
>>>
>>> Thats a great idea, i will do this.
>>>
>>> Best regards
>>> Soeren
>>>
>>>
>>>>
>>>> Hamish
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> grass-dev mailing list
>>> grass-dev at grass.itc.it
>>> http://grass.itc.it/mailman/listinfo/grass-dev
>>>
>>>
>>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
More information about the grass-dev
mailing list