[GRASS-dev] g3dcell [was: g.remove --q]

Hamish hamish_nospam at yahoo.com
Tue Oct 10 00:41:47 EDT 2006


Glynn Clements wrote:
> BTW, etc/element_list doesn't distinguish between "core" elements
> (e.g. cellhd, cell etc) and ancilliary elements (history, color etc). 
> Ideally, it shouldn't be possible to have the latter without the
> former, but I wouldn't assume that it's completely impossible in
> practice.

there should be a way to remove broken maps.


> For now, I think we'll have to be satisfied with distinguishing
> between zero elements existing and one or more elements existing,
> regardless of the signficance of the elements.
> 
> > >>> g3dcell MISSING
> > 
> > >> BTW, I'd like to ask again what is the g3dcell?
> > 
> > > No idea.
> > 
> > Could it be removed then?
> 
> No idea.

general request:
 Please err on the side of caution when dealing with unknown code.

GRASS is too big, too complex, too much history to start removing stuff
just because the current crop of developers aren't familiar with it.

grep, cvs, and mailing list searches must be done:

grepping for g3dcell doesn't find much, just lib/gis/opencell.c
That is in the GRASS 5 cvs since the beginning of the cvs (1999).

but,
grass63$ grep -rI g3d * | wc -l
1651

see lib/g3d/   lib/g3d/snap.gif

The r3.* modules #include <grass/G3d.h> and depend on libgrass_g3d.so


3D rasters are now stored in $MAPSET/grid3/$MAPNAME/cell, so probably
g3dcell is an old place for that and is now unused.

Maybe Helena knows...?



Hamish




More information about the grass-dev mailing list