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

Maciej Sieczka tutey at o2.pl
Sun Oct 8 09:48:42 EDT 2006

Glynn Clements wrote:

> 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).

>>> 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.

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.

>> 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.

>>> g3dcell MISSING

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

> No idea.

Could it be removed then?

>> 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?


More information about the grass-dev mailing list