[GRASS-dev] [GRASS GIS] #2475: g.findfile type/element support not clear

GRASS GIS GRASS GIS developer
1

#2475: g.findfile type/element support not clear
--------------------------------------------------------------------------------------+
Reporter: wenzeslaus | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: g.findfile, find_file, types, elements, cell, fcell, dcell, rast, rast3d | Platform: Unspecified
      Cpu: Unspecified |
--------------------------------------------------------------------------------------+
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?

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2475&gt;
GRASS GIS <http://grass.osgeo.org>

2

#2475: g.findfile type/element support not clear
--------------------------------------------------------------------------------------+
Reporter: wenzeslaus | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: g.findfile, find_file, types, elements, cell, fcell, dcell, rast, rast3d | Platform: Unspecified
      Cpu: Unspecified |
--------------------------------------------------------------------------------------+

Comment(by glynn):

Replying to [ticket:2475 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.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2475#comment:1&gt;
GRASS GIS <http://grass.osgeo.org>

3

#2475: g.findfile type/element support not clear
----------------------------------------------------------------------------------------------------------+
Reporter: wenzeslaus | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: g.findfile, find_file, types, elements, cell, fcell, dcell, rast, rast3d, API change, g.list | Platform: Unspecified
      Cpu: Unspecified |
----------------------------------------------------------------------------------------------------------+
Changes (by wenzeslaus):

  * keywords: g.findfile, find_file, types, elements, cell, fcell, dcell,
               rast, rast3d => g.findfile, find_file, types,
               elements, cell, fcell, dcell, rast, rast3d,
               API change, g.list

Comment:

Replying to [comment:1 glynn]:
> Replying to [ticket:2475 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.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2475#comment:2&gt;
GRASS GIS <http://grass.osgeo.org>

4

#2475: g.findfile type/element support not clear
----------------------------------------------------------------------------------------------------------+
Reporter: wenzeslaus | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: g.findfile, find_file, types, elements, cell, fcell, dcell, rast, rast3d, API change, g.list | Platform: Unspecified
      Cpu: Unspecified |
----------------------------------------------------------------------------------------------------------+

Comment(by glynn):

Replying to [comment:2 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).

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2475#comment:3&gt;
GRASS GIS <http://grass.osgeo.org>