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

[Helena Mitasova]

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 at gclements.plus.com>