g.findfile type/element support not clear

[wenzeslaus]

There is some issue in G7:g.findfile interface or implementation.

If you list elements, rast is present:

GRASS > g.findfile -l
List of available elements:
  rast      (raster map(s))
  rast3d    (3D raster map(s))
  vect      (vector map(s))
  oldvect   (old (GRASS 5.0) vector map(s))
  asciivect (ASCII vector map(s))
  labels    (paint label file(s))
  region    (region definition(s))
  region3d  (3D region definition(s))
  group     (imagery group(s))

But look for the elevation with element=rast and you get nothing:

GRASS > g.findfile element=rast file=elevation
name=
mapset=
fullname=
file=

element=cell works as well as element=fcell:

GRASS > g.findfile element=cell file=elevation
name='elevation'
mapset='PERMANENT'
fullname='elevation@PERMANENT'
file='.../PERMANENT/cell/elevation'
GRASS > g.findfile element=fcell file=elevation
name='elevation'
mapset='PERMANENT'
fullname='elevation@PERMANENT'
file='.../PERMANENT/fcell/elevation'

What is the right behavior? It seems that there is a difference between element and type, is this true? What is appropriate for g.findfile? What would be the value for file key if g.findfile would support type=rast etc. instead of element=cell|fcell|dcell? What about 3D rasters?

[glynn]

Replying to wenzeslaus:

What is the right behavior? It seems that there is a difference between element and type, is this true? What is appropriate for g.findfile? What would be the value for file key if g.findfile would support type=rast etc. instead of element=cell|fcell|dcell? What about 3D rasters?

The argument to element= should be the name of an actual element (e.g. cell), not the alias (e.g. rast).

But -l probably shouldn't be listing the aliases. I'm not sure the -l flag should even exist.

[wenzeslaus]

Replying to glynn:

Replying to wenzeslaus:

What is the right behavior? It seems that there is a difference between element and type, is this true? What is appropriate for g.findfile? What would be the value for file key if g.findfile would support type=rast etc. instead of element=cell|fcell|dcell? What about 3D rasters?

The argument to element= should be the name of an actual element (e.g. cell), not the alias (e.g. rast).

But -l probably shouldn't be listing the aliases. I'm not sure the -l flag should even exist.

I was thinking about what is actual purpose of g.findfile. If I'm looking for raster, vector etc. as I would list them using g.list I'm interested in types, not elements.

If I'm interested in the files, then I run g.findfile. If I'm searching DCELL raster, I ask for elemenet=dcell, similarly for FCELL, but if I'm interested in searching for CELL, I got uncertain result because the map I found might be CELL as well as FCELL or DCELL. So what is the g.findfile actually good for?

And since g.findfile has the strange interface, wouldn't be better to use g.list for checking if map exists and getting its mapset? This is anyway most of the usages of find_file() from grass.script.core, I guess.

> g.list type=rast pattern=elevation -m
elevation@PERMANENT
> echo $?
0
> g.list type=rast pattern=xxx -m
> echo $?
0

We don't need to solve the g.findfile -> g.list transition since it would be probably introduction of new function of to the library (rather then changing find_file() function), however we should decide the purpose and interface of g.findfile.

Related to this, g.findfile exits with 1 if nothing was found and prints only keys (but prints) while other modules are more quiet (hard to say what's better when). Also the other parameter is called file, it should be called name I think.

[glynn]

Replying to wenzeslaus:

If I'm interested in the files, then I run g.findfile. If I'm searching DCELL raster, I ask for elemenet=dcell,

That won't work. There is no "dcell" elements; the data file for floating-point maps is stored in fcell/<name> regardless of precision. Also, all raster maps have a "cell" element; it's just empty for floating-point and reclass maps.

but if I'm interested in searching for CELL, I got uncertain result because the map I found might be CELL as well as FCELL or DCELL.

GRASS doesn't directly provide any functionality to search for maps satisfying criteria more specific than the mapset or type (raster or vector).

So what is the g.findfile actually good for?

g.findfile primarily makes G_find_file() available to scripts.

It's used for finding whether something exists, in which mapset it exists, and the actual filename for a particular element.

And since g.findfile has the strange interface, wouldn't be better to use g.list for checking if map exists and getting its mapset?

Using g.list is more expensive; potentially much more expensive if the mapset contains a large number of maps or is on a remote filesystem.

Also, enumeration requires read permission on the directory, whereas accessing specific files only requires execute permission. This probably won't be an issue for GRASS databases, but the general principle is worth remembering (e.g. it's not uncommon for servers to use default directory permissions of 0751 = "drwxr-x--x" so that unprivileged users can use what they actually need but can't "explore" the filesystem).