[GRASS-dev] r.mapcalc and g.remove --v/q issues

[Glynn Clements]

Maciej Sieczka wrote:

> >> Propably due to the recent work on --v and --q flags (great stuff, many
> >> thanks to the authors!), r.mapcalc doesn't print any progress indicator
> >> anymore.
> 
> > AFAIK, modules are quiet by default now. If you want verbosity (e.g.
> > progress indication) you have to enable it.
> 
> I didn't realize that quiet mode implies no progress indicator. In that
> case verbose should be the default IMO, because we can't leave users
> without a feedback from the module progress unless they implicitely
> requests that. Am I wrong?

Yes. The normal behaviour for Unix command-line programs is not to
print anything unless something unexpected happens.

> > Specifying a map which doesn't exist (one with no elements) has never
> > been an error.
> 
> Not really, it is an error in case of vectors already. Try this:
> 
> $ g.remove vect=dummy

It has never been an error for rasters (or other types), and wasn't
for vectors until the vector subsystem was changed to the DBMI-backed
implementation.

The fact that it's now an error for vectors (and only vectors) is
essentially an oversight.

When vector maps ceased to be simply a collection of files, the
general/manage code needed to be modified for that specific case. If
you look at the code, you will note that most of it is "generic"; it
applies to any type of entity which is defined in the
$GISBASE/etc/element_list. Vectors are a hard-coded special case.

> > At most, it should generate a warning if no elements
> > are found.
> 
> Why shouldn't it generate an error? The user is trying to use a
> non-existant map for the g.remove input. Other modules return an error
> in such case. g.remove vect does the same. But g.remove
> rast/rast3d/region/group doesn't. Shouldn't they conform?

Compatibility. Management commands are used extensively in scripts.

Apart from anything else, generating an error at the point that the
specific map is processed (the way that vectors are currently handled)
means that it won't even attempt to remove any subsequent maps. E.g.

	g.remove vect=vect1,vectnonexist,vect2

will abort on vectnonexist and won't attempt to remove vect2.

> Also, in the verbose mode, only a single-line information like "Raster
> map <dummy> removed" should be printed insated of the current 9 lines:
> 
> $ g.remove rast=dummy --v
> REMOVE [dummy]
> raster
> header
> category
> color MISSING
> history
> misc
> fcell MISSING
> g3dcell MISSING

IMHO, verbose mode should display everything, quiet mode should
display a single warning for each map with no elements (i.e. the map
doesn't exist).

> BTW, I'd like to ask again what is the g3dcell?

No idea.

> Talking of g.remove - could the following types should be disposed in
> GRASS 7?:
> 
> 1. sites - there is no sites functionality in Grass>=5.7
> 2. region3d - 3D region settings have been merged into region
> 3. 3dview - remainment of Grass <5.7 3d.view command
> 4? icon - I don't know, propably too? what is it?
> 5. oldvect
> 6. asciivect
> 
> Same applies to g.copy/rename/list

Removing them from copy/rename seems reasonable enough. However you
might upgrade from 5.x to 6.x but still have 5.x entities left in the
database directories, so you need some way to remove them.

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