[GRASS-dev] Enhancement request: print name(s) of generated map(s) upon completion

neteler · June 2, 2014, 6:15pm

Hi,

as general improvement I would like to see that each map generating GRASS command prints the name(s) of the generated maps. This is especially relevant when multiple maps can generated (e.g. r.watershed).

I have today added such support in v.vol.rst but wondered if a more generic possibility exists at library level.
For raster maps, this ugly hack works:

Index: lib/raster/history.c

— lib/raster/history.c (revision 60664)
+++ lib/raster/history.c (working copy)
@@ -162,6 +162,7 @@
G_fatal_error(_(“Unable to write history information for <%s>”), name);

Rast__write_history(hist, fp);

G_done_msg(_(“Raster map <%s> created”), name);
}

Interestingly, it gets printed twice then:

using GRASS 7.1.svn (nc_spm_08_grass7):~ >

r.mapcalc “result = if(landclass96 == 5, 1, null() )”
100%
r.mapcalc complete. Raster map created
r.mapcalc complete. Raster map created

Likewise another example:

using GRASS 7.1.svn (nc_spm_08_grass7):~ >

g.region rast=elev_lid792_1m
r.watershed elevation=elev_lid792_1m accumulation=elev_lid792_1m.acc2
basin=elev_lid792_1m.basin2 stream=elev_lid792_1m.stream2
tci=elev_lid792_1m.tci2 threshold=1000
SECTION 1a (of 5): Initiating Memory.
SECTION 1b (of 5): Determining Offmap Flow.
100%
…
SECTION 5: Closing Maps.
100%
ram complete. Raster map <elev_lid792_1m.stream2> created
ram complete. Raster map <elev_lid792_1m.basin2> created
ram complete. Raster map <elev_lid792_1m.acc2> created
ram complete. Raster map <elev_lid792_1m.tci2> created
r.watershed complete. Raster map <elev_lid792_1m.acc2> created
r.watershed complete. Raster map <elev_lid792_1m.tci2> created
r.watershed complete. Raster map <elev_lid792_1m.basin2> created
r.watershed complete. Raster map <elev_lid792_1m.stream2> created

For vector maps, a similar mechanism would be ideal.

Ideas?

Markus

mlennert · June 5, 2014, 3:51pm

On 02/06/14 20:15, Markus Neteler wrote:

Hi,

as general improvement I would like to see that each map generating
GRASS command prints the name(s) of the generated maps. This is
especially relevant when multiple maps can generated (e.g. r.watershed).

I have today added such support in v.vol.rst but wondered if a more
generic possibility exists at library level.
For raster maps, this ugly hack works:

Index: lib/raster/history.c

--- lib/raster/history.c (revision 60664)
+++ lib/raster/history.c (working copy)
@@ -162,6 +162,7 @@
   G_fatal_error(_("Unable to write history information for <%s>"), name);

      Rast__write_history(hist, fp);
+ G_done_msg(_("Raster map <%s> created"), name);
  }

Interestingly, it gets printed twice then:

# using GRASS 7.1.svn (nc_spm_08_grass7):~ >
r.mapcalc "result = if(landclass96 == 5, 1, null() )"
  100%
r.mapcalc complete. Raster map <result> created

Likewise another example:

# using GRASS 7.1.svn (nc_spm_08_grass7):~ >
  g.region rast=elev_lid792_1m
r.watershed elevation=elev_lid792_1m accumulation=elev_lid792_1m.acc2 \
    basin=elev_lid792_1m.basin2 stream=elev_lid792_1m.stream2 \
    tci=elev_lid792_1m.tci2 threshold=1000
SECTION 1a (of 5): Initiating Memory.
SECTION 1b (of 5): Determining Offmap Flow.
  100%
...
SECTION 5: Closing Maps.
  100%
ram complete. Raster map <elev_lid792_1m.stream2> created
ram complete. Raster map <elev_lid792_1m.basin2> created
ram complete. Raster map <elev_lid792_1m.acc2> created
ram complete. Raster map <elev_lid792_1m.tci2> created
r.watershed complete. Raster map <elev_lid792_1m.acc2> created
r.watershed complete. Raster map <elev_lid792_1m.tci2> created
r.watershed complete. Raster map <elev_lid792_1m.basin2> created
r.watershed complete. Raster map <elev_lid792_1m.stream2> created

For vector maps, a similar mechanism would be ideal.

Ideas?

Sounds quite verbose to me. Why do we need this ? Maybe make this conditional to --verbose ?

Moritz

neteler · June 5, 2014, 4:29pm

On Thu, Jun 5, 2014 at 5:51 PM, Moritz Lennert <mlennert@club.worldonline.be> wrote:

On 02/06/14 20:15, Markus Neteler wrote:

Hi,

as general improvement I would like to see that each map generating
GRASS command prints the name(s) of the generated maps. This is
especially relevant when multiple maps can generated (e.g. r.watershed).
…
wondered if a more
generic possibility exists at library level.
…

[as written, that example was ugly]

Sounds quite verbose to me. Why do we need this ? Maybe make this
conditional to --verbose ?

Dunno. Example - this I got from a user:

v.vol.rst -c input=utm3d@UTMfinish wcolumn=temp tension=10. cvdev=cvdevmap38 maskmap=ter@UTMfinish segmax=698 npmin=699 dmin=150.0 zmult=50.0
6283 records selected from table
Processing all selected output files will require 0 bytes of disk space for temp files
WARNING: Points are more dense than specified ‘DMIN’–ignored 5938 points (remain 345)
WARNING: 345 points given for interpolation (after thinning) is less than given NPMIN=699
WARNING: There is less than 700 points for interpolation, no segmentation is necessary, to run the program faster, set segmax=700 (see manual)
bitmap mask created
Percent complete:
Finished interpolating
Building topology for vector map …
Registering primitives…
334 primitives registered
334 vertices registered
Building areas…
0 areas built
0 isles built
Attaching islands…
Attaching centroids…
Number of nodes: 334
Number of primitives: 334
Number of points: 334
Number of lines: 0
Number of boundaries: 0
Number of centroids: 0
Number of areas: 0
Number of isles: 0
The number of points in vector map is 6283
The number of points outside of 2D/3D region 0
The number of points used (after reduction) is 345
(Sat May 31 11:09:50 2014) Command finished (26 sec)

… he told me that nothing got calculated (apparently he didn’t use g.list).
Indeed the information is quite buried in above output. Also r.watershed with multiple output does not say much.

That’s why I would see the generated map names printed out.

Markus

mlennert · June 5, 2014, 6:16pm

On 05/06/14 18:29, Markus Neteler wrote:

<mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be>> wrote:
> Sounds quite verbose to me. Why do we need this ? Maybe make this
> conditional to --verbose ?

Dunno. Example - this I got from a user:

v.vol.rst -c input=utm3d@UTMfinish wcolumn=temp tension=10.
cvdev=cvdevmap38 maskmap=ter@UTMfinish segmax=698 npmin=699 dmin=150.0
zmult=50.0

[...]

... he told me that nothing got calculated (apparently he didn't use
g.list).
Indeed the information is quite buried in above output. Also r.watershed
with multiple output does not say much.

That's why I would see the generated map names printed out.

I understand the concern, but I wonder up to which point we have to hold the user's hand. The information is easily available in the man page.

This is as if in R you would write out information about every single output value a function gives you. In my eyes this would be horrible.

Let's leave at least part of the responsibility for understanding how to use GRASS to the user...

Moritz

neteler · June 5, 2014, 6:44pm

On Thu, Jun 5, 2014 at 8:16 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
...

I understand the concern, but I wonder up to which point we have to hold the user's hand. The information is easily available in the man page.

This is as if in R you would write out information about every single output value a function gives you. In my eyes this would be horrible.

I was referring to the output maps being created, nothing else.
That can be 0 to some outputs.

Let's leave at least part of the responsibility for understanding how to use GRASS to the user...

I myself miss it a lot if that matters

Markus

wenzeslaus · June 5, 2014, 6:47pm

On Thu, Jun 5, 2014 at 2:44 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Thu, Jun 5, 2014 at 8:16 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
...
> I understand the concern, but I wonder up to which point we have to hold
the user's hand. The information is easily available in the man page.
>
> This is as if in R you would write out information about every single
output value a function gives you. In my eyes this would be horrible.

I was referring to the output maps being created, nothing else.
That can be 0 to some outputs.

> Let's leave at least part of the responsibility for understanding how to
use GRASS to the user...

I myself miss it a lot if that matters

Hm, if the message(s) would be parseable independently on the language
settings (perhaps with message format set to GUI), GUI could use that
information to add/re-render the layers. (Instead of current guessing based
on the parameters.)

Also if we will say no to the messages, we should remove them from all the
modules because than users expect to see then in all modules.

What you are saying about R makes sense but in case of GRASS, the modules
are much more verbose (even without --verbose) than R functions (e.g.
topology building), so few lines more does not make any difference IMHO.

Vaclav

Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Mohammed_Rashad · June 5, 2014, 7:28pm

Hi,

I would like to add a +1 to Mortiz here. This enhancement should be in the verbose. Like there are debug level for message. These message can be like level in verbose. say --verbose=1

···

On Thu, Jun 5, 2014 at 8:44 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Thu, Jun 5, 2014 at 8:16 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
…

I understand the concern, but I wonder up to which point we have to hold the user’s hand. The information is easily available in the man page.

This is as if in R you would write out information about every single output value a function gives you. In my eyes this would be horrible.

I was referring to the output maps being created, nothing else.
That can be 0 to some outputs.

Let’s leave at least part of the responsibility for understanding how to use GRASS to the user…

I myself miss it a lot if that matters

Markus

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

–

Regards,
Rashad

wenzeslaus · June 5, 2014, 8:10pm

On Thu, Jun 5, 2014 at 3:28 PM, Rashad M <mohammedrashadkm@gmail.com> wrote:

I would like to add a +1 to Mortiz here. This enhancement should be in
the verbose. Like there are debug level for message. These message can be
like level in verbose. say --verbose=1

--verbose, or something like it, might work for GUI but it is not solving
what Markus wanted, so in this case there is no point of adding the
messages there since the user-beginner will be confused from not getting
the maps and not aware of --verbose.

In other words, compromise does not solve anything in this case. To address
the issue, we should either put the message everywhere or nowhere and in
addition remove some of the messages (such as vector topology build) which
also gives users false expectations of getting the names of results.

neteler · June 5, 2014, 8:38pm

On Thu, Jun 5, 2014 at 9:28 PM, Rashad M <mohammedrashadkm@gmail.com> wrote:

Hi,

I would like to add a +1 to Mortiz here. This enhancement should be in the
verbose. Like there are debug level for message. These message can be like
level in verbose. say --verbose=1

I would suggest to do the opposite. Since percentage output is there,
it would be helpful to
- vector: put e.g. most of the many topology related messages
(v.clean, v.in.ogr) into verbose,
- raster: do the same for candidates like r.watershed, many messages...

==> But then tell the user what has been produced!

The point is: if you run stuff on command line/in batch jobs, you want
to know the outcome, not how many tiny interim steps have been done.
Sure I can scroll back but GRASS could also simply tell me.

Just my 0.02 cents (from my teaching experience with GIS experts but
GRASS newbies),

Markus

mlennert · June 6, 2014, 6:52am

On 05/06/14 22:38, Markus Neteler wrote:

On Thu, Jun 5, 2014 at 9:28 PM, Rashad M <mohammedrashadkm@gmail.com> wrote:

Hi,

I would like to add a +1 to Mortiz here. This enhancement should be in the
verbose. Like there are debug level for message. These message can be like
level in verbose. say --verbose=1

I would suggest to do the opposite. Since percentage output is there,
it would be helpful to
- vector: put e.g. most of the many topology related messages
(v.clean, v.in.ogr) into verbose,
- raster: do the same for candidates like r.watershed, many messages...

==> But then tell the user what has been produced!

The point is: if you run stuff on command line/in batch jobs, you want
to know the outcome, not how many tiny interim steps have been done.
Sure I can scroll back but GRASS could also simply tell me.

I agree with you on the suggestion to output less of the topological info. I'm still not convinced by the need for printing the names of maps that are created.

Just my 0.02 cents (from my teaching experience with GIS experts but
GRASS newbies),

Same here

Moritz