[GRASS-dev] Re: g3dcell [was: g.remove --q]
hmitaso at unity.ncsu.edu
Tue Oct 10 09:11:55 EDT 2006
On Oct 10, 2006, at 12:41 AM, Hamish wrote:
> 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
> 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
> 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).
> grass63$ grep -rI g3d * | wc -l
> 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...?
yes, that is right - sorry for not responding earlier, I just thought
I should verify it first,
thanks for doing that,
More information about the grass-dev