[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.
> 
> GRASS modules are not 'normal UNIX programs'. A user must be informed
> if there's a progress. Otherwise he will not even know if the module
> freezed or what. I fully second what Hamish says in this regard (in his
> post in this thread).

On that, we'll just have to disagree. It isn't important, as the user
can just set GRASS_VERBOSE explicitly if the default value isn't to
their liking.

> > 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.
> 
> Fine. Then g.remove vect should be fixed to behave like the other
> types, and a non-fatal "WARNING: Vector map <dummy> not found" shoud be
> issued if needed. Same for all other types. And, most importantly,
> those warnings should issued by default, unless the user requests
> g.remove to run quietly (which implies that a verbose mode should be
> the default). Otherwise the user will not know that the map he tried to
> remove doesn't exist.

Warnings are supposed to be issued even at minimum verbosity. It's the
more detailed output which needs to vary according the verbosity
settings.

> >> 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).
> 
> But all those lines: raster, header, category, color, history, misc,
> fcell are meaningless for a normal user. He should only be told that
> "Raster map <blahblah> was removed". Why does one need to read all
> those lines anyway? They don't give any usefull information but
> distract and occupy space on the terminal. They should be displayed
> only at a higher DEBUG level.

In retrospect, I agree that those should be considered "debug"
information. Historically, they have been the only way to discover
that a map is entirely absent.

BTW, etc/element_list doesn't distinguish between "core" elements
(e.g. cellhd, cell etc) and ancilliary elements (history, color etc). 
Ideally, it shouldn't be possible to have the latter without the
former, but I wouldn't assume that it's completely impossible in
practice.

For now, I think we'll have to be satisfied with distinguishing
between zero elements existing and one or more elements existing,
regardless of the signficance of the elements.

> >>> g3dcell MISSING
> 
> >> BTW, I'd like to ask again what is the g3dcell?
> 
> > No idea.
> 
> Could it be removed then?

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
> 
> I'm talking about GRASS 7.
> 
> > but still have 5.x entities left in the database directories, so
> > you need some way to remove them.
> 
> The question might be: is GRASS 7 supposed to provide tools to make the
> switch from GRASS 5 easy, like GRASS 6 does?

I see no reason to remove that functionality, given that it's
essentially a few lines in the element_list file. None of this is
actually coded.

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