[GRASS-dev] New raster-to-raster3d conversion module

Dear devs,
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

The module sources are available here:
http://www-pool.math.tu-berlin.de/~soeren/grass/modules/r.elev.to.rast3.tar.gz

A sample screenshot of the spearfish dataset:
http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/r.elev.to.rast3_spearfish.png

This data was created with r.elev.to.rast3, exported with r3.out.vtk and visualized with Paraview (i used
the threshold filter and the opacity functionality, to separate the ground from the air).
This example is included in the documentation of the module (description.html).

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.

Maybe someone want to test this module. A short description with examples
is available in the tar.gz file.

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.
If somebody has a any ideas how to improve the existing modules, or about a new module,
please tell me. I will try to implement it.

Any suggestions, opinions are welcome.

Best regards
Soeren

btw.:
I have posted this mail to the grass-user list too. Maybe someone of the users want to
test it. :slight_smile:

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!

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)

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.

Hamish

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

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?

3D functionality in GRASS is really getting somewhere.
The only things I could wish for:

1. Make volume vizualization work in NVIZ
2. Module to convert 3D Polygon -> 3D raster map
3. Module to query 3d raster value using 3D vector points/coordinates
4. Categorization and information like r.report provides

Maybe for GRASS 6.2?

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@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

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. :wink:

Maybe for GRASS 6.2?

You are welcome to help implementing this. :slight_smile:

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@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>
>

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. :wink:

Maybe for GRASS 6.2?

You are welcome to help implementing this. :slight_smile:

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@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

Dear Helena,

On Friday 14 July 2006 18:53, Helena Mitasova wrote:

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?

Sorry, i did not informed me about the maximum command name length, so
i chosed r.elev.to.rast3 because that was the best name i found and this name
explaned the usage correctly.
And i dont wanted to extent r.to.rast3 to avoid to many confusing options.
Maybe you or somebody else can help me in finding a better name?
How about r.elev.rast3 or r.elev.torast3?

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.

Yes, you are right! We absolutely have to avoid longer and messier names.
Is there already a guidline about grass name creation?
If not, we should create one.
But how to make sure that meaningful names are
always possible with two dots?

Best
Soeren

Helena

Soeren Gebbert wrote:

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.

I'm not sure if I mentioned this before, if I did please ignore the
duplicate.

consider renaming the module "r.to.rast3.elev" (or similar) so like
modules are grouped together both in the help pages and logically.

thanks,
Hamish

On Jul 15, 2006, at 7:44 AM, Hamish wrote:

Soeren Gebbert wrote:

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.

I'm not sure if I mentioned this before, if I did please ignore the
duplicate.

consider renaming the module "r.to.rast3.elev" (or similar) so like
modules are grouped together both in the help pages and logically.

given my previou notes about the 2 dots, it looks like r.to.rast3elev
would be a good choice,

Helena

thanks,
Hamish

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

Helena Mitasova wrote:

>> 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.
>
>
> I'm not sure if I mentioned this before, if I did please ignore the
> duplicate.
>
> consider renaming the module "r.to.rast3.elev" (or similar) so like
> modules are grouped together both in the help pages and logically.

given my previou notes about the 2 dots, it looks like r.to.rast3elev
would be a good choice,

Is there any particuarl reason for imposing a "two dots" restriction?

--
Glynn Clements <glynn@gclements.plus.com>

On Jul 15, 2006, at 7:56 PM, Glynn Clements wrote:

Helena Mitasova wrote:

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.

I'm not sure if I mentioned this before, if I did please ignore the
duplicate.

consider renaming the module "r.to.rast3.elev" (or similar) so like
modules are grouped together both in the help pages and logically.

given my previou notes about the 2 dots, it looks like r.to.rast3elev
would be a good choice,

Is there any particuarl reason for imposing a "two dots" restriction?

just to avoid getting the names out of control - imagine the man page
http://grass.itc.it/grass61/manuals/html61_user/raster.html

with command names such as
r.slope.aspect.curv.polyn2nd.vers3

and they can easily lose any logic, such as
s.surf.rst.vol.time.cv (we actually had that kind of name for a development version of s.volt.rst)

We can certainly have longer module names but I would suggest some rules
on how to keep them meaningful and logical.

Helena

P.S. I looked at the man pages and surprisingly there are almost no offenders
to the two dots max rule in spite of the fact that this has never been an official rule.
(v.db.reconnect.all and v.in.sites.all are the exception and they are recent additions)

--
Glynn Clements <glynn@gclements.plus.com>