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

[GRASS GIS]

#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 at 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>
GRASS GIS <http://grass.osgeo.org>