[GRASS-dev] raster3D vs raster3d used as elements

Hi,

I'm a bit confused about how lib/gis/element_list deals with raster3d
stuff.

the source code path is ./raster3d/r3.*/main.c ...

the human-readable alias in the help pages is "raster3D"

MAPSETs in the past used g3dcell/ but now seem to use grid3/
but there are still a couple of references to g3dcell in e.g.
lib/gis/opencell.c || lib/raster/open.c

technically a grass "element" is == a dir in $MAPSET, so "grid3"?

element_list itself seems clear enough.

the g.extension test for grass6 is r3.in.xyz

I fear that parts of r49694 and r49695 may be in error, please review.

stopping before I do any more damage,
Hamish

Hamish wrote:

I'm a bit confused about how lib/gis/element_list deals with raster3d
stuff.

the source code path is ./raster3d/r3.*/main.c ...

the human-readable alias in the help pages is "raster3D"

MAPSETs in the past used g3dcell/ but now seem to use grid3/
but there are still a couple of references to g3dcell in e.g.
lib/gis/opencell.c || lib/raster/open.c

It has been grid3 since at least 5.3 (there is no equivalent in
4.2.1).

g3dcell is an element of 2D rasters, but it appears to be ancient
history. The only references in the source code (which go back to 5.3
and persist in 7.0) are the checks for the type of a raster map
(Rast_map_is_fp() and Rast_map_type() consider a map as DCELL if it
has a g3dcell element).

I fear that parts of r49694 and r49695 may be in error, please review.

The element_list file says that it's "raster3D" with an upper-case
"D".

Note that the etc/element_list file is only used by the management
commands (g.list, g.remove, g.copy, g.rename), which is why it was
historically in general/manage/lib, and is in lib/manage in 7.0. The
detour to lib/gis occurred between 6.3.0 and 6.4.0.

The field in question is used as the "prompt" component of the
option's ->gisprompt field, and in progress messages. I don't know how
the GUI uses that information, but GRASS itself only uses it for the
G_ask_* functions (which have been removed in 7.0). As it's intended
to be human-readable rather than machine-readable, it should probably
be considered for localisation.

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