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

Martin Landa landa.martin at gmail.com
Sun Oct 8 11:39:00 EDT 2006


Hi,

trying to cleanup g.remove module I have prepared the patch. Is it OK
for you? Any comments welcomed...

Best regards, Martin

2006/10/8, Maciej Sieczka <tutey at o2.pl>:
> 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?
>
> > As r.mapcalc doesn't use G_parser(), --v won't work; you would need to
> > set GRASS_VERBOSE.
> >
> > There probably needs to be a "stub" version of G_parser() which
> > implements the built-in switches (--help, --verbose etc) but doesn't
> > attempt to parse the entire command line.
> >
> > Changing the syntax of r.mapcalc to conform to the normal convention
> > would probably be too radical a change. While we can fix our own
> > scripts, there are likely to be a lot of home-grown scripts which
> > would be broken (not to mention users who are accustomed to using the
> > existing syntax from the command line).
>
> If verbose would be the default that would also fix the problem of
> no-progress in r.mapcalc by default.
>
> >> Also g.remove doesn't return any info if trying to remove a
> >> non-existant map. If used with --v it will print eg.:
> >>
> >> $ g.remove rast=dummy --v
> >> REMOVE [dummy]
> >> raster MISSING
> >> header MISSING
> >> category MISSING
> >> color MISSING
> >> history MISSING
> >> misc MISSING
> >> fcell MISSING
> >> g3dcell MISSING
> >>
> >> as it used before introducing --q and --v. But if --v is not
> >> explicitely set (default), it will remain silent.
> >>
> >> It should print "ERROR: raster map <dummy> not found" instead.
>
> > 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
>
> you'll get:
>
> ERROR: Vector map <dummy> not found
>
> $ echo $?
> 1
>
> > 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?
>
> 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
>
> BTW, I'd like to ask again what is the g3dcell?
>
>
>
>
>
> 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
>
> ?
>
> Maciek
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>


-- 
Martin Landa <landa.martin at gmail.com> * http://gama.fsv.cvut.cz/~landa *
-------------- next part --------------
A non-text attachment was scrubbed...
Name: g_remove.diff.gz
Type: application/x-gzip
Size: 2141 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20061008/936b925a/g_remove.diff.gz


More information about the grass-dev mailing list