wish: less verbose messages in rgrass7

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

wish: less verbose messages in rgrass7

Markus Neteler
Hi,

today we used "rgrass7" on Windows (and I made some tests on Linux, too).

I was wondering about a few warnings which might be suppressed to avoid user confusion:


######## Windows: calling GRASS 7.1 from R session

> library(rgrass7)
Loading required package: sp
Loading required package: XML
GRASS GIS interface loaded with GRASS version: (GRASS not running)
Warning messages:
1: package ‘rgrass7’ was built under R version 3.2.2 
2: package ‘sp’ was built under R version 3.2.2 
3: package ‘XML’ was built under R version 3.2.2

> initGRASS(gisBase = "C:/OSGeo4W/apps/grass/grass-7.1.svn",
+ gisDbase = "C:/Users/marissa/GRASSdata/",
+ location = "CA", mapset = "Aegypti")
Error in initGRASS(gisBase = "C:/OSGeo4W/apps/grass/grass-7.1.svn", gisDbase = "C:/Users/marissa/GRASSdata/",  : 
  A GISRC file already exists; to override, set override=TRUE


==> the last sentence is not quite clear. Perhaps change to

"A GISRC file already exists (the GRASS GIS mapset is already in use); to override, set override=TRUE"


> initGRASS(gisBase = "C:/OSGeo4W/apps/grass/grass-7.1.svn",
+ gisDbase = "C:/Users/marissa/GRASSdata/",
+ location = "CA", mapset = "Aegypti",
+ override=TRUE)
gisdbase    C:/Users/marissa/GRASSdata/ 
location    CA 
mapset      Aegypti 
rows        265 
columns     230 
north       452000 
south       -608000 
west        -376000 
east        544000 
nsres       4000 
ewres       4000 
projection  +proj=aea +lat_1=34 +lat_2=40.5 +lat_0=0 +lon_0=-120 +x_0=0 +y_0=-4000000 +no_defs +a=6378137 +rf=298.257222101
+towgs84=0.000,0.000,0.000 +to_meter=1 
Warning message:
In dir.create(gisDbase) : 'C:\Users\marissa\GRASSdata' already exists

==> the last warning is not clear to me. If I set override=TRUE, I refer to the mapset's gislock, hence the dir.create(gisDbase should not be done at all. Is it a bug?


############## Linux

> ncdata <- readRAST("elevation")
WARNING: 'cellhd/elevation' was found in more mapsets (also found in
         <PERMANENT>)
WARNING: Using <elevation@user1>
WARNING: 'cellhd/elevation' was found in more mapsets (also found in
         <PERMANENT>)
WARNING: Using <elevation@user1>
WARNING: 'cellhd/elevation' was found in more mapsets (also found in
         <PERMANENT>)
WARNING: Using <elevation@user1>

==> these warning make probably sense in a GRASS session but IMHO here less. They could be suppressed with --q in the respective GRASS module call.


Creating BIL support files...
Exporting raster as floating values (bytes=4)
 100%
Warning messages:
1: In execGRASS("r.info", flags = "g", map = vname[i], intern = TRUE,  :
  The command:
r.info -g map=elevation
produced at least one warning during execution:
WARNING: 'cellhd/elevation' was found in more mapsets (also found in
         <PERMANENT>)
WARNING: Using <elevation@user1>
WARNING: 'cellhd/elevation' was found in more mapsets (also found in
         <PERMANENT>)
WARNING: Using <elevation@user1>
WARNING: 'cellhd/elevation' was found in more mapsets (also found in
         <PERMANENT>)
WARNING: Using <elevation@user1>

==> here it is, I suggest to use r.info --q

2: In execGRASS("r.info", flags = "r", map = vname[i], intern = TRUE,  :
  The command:
r.info -r map=elevation
produced at least one warning during execution:
WARNING: 'cellhd/elevation' was found in more mapsets (also found in
         <PERMANENT>)
WARNING: Using <elevation@user1>
WARNING: 'cellhd/elevation' was found in more mapsets (also found in
         <PERMANENT>)
WARNING: Using <elevation@user1>
WARNING: 'cellhd/elevation' was found in more mapsets (also found in
         <PERMANENT>)
WARNING: Using <elevation@user1>

==> same thing

3: In execGRASS("r.out.bin", flags = rOutBinFlags, input = vname[i],  :
  The command:
r.out.bin -b -f input=elevation output=/home/neteler/grassdata/nc_spm_08_grass7/user1/.tmp/pgis_north/elevation bytes=4 null=54
produced at least one warning during execution:
WARNING: 'cellhd/elevation' was found in more mapsets (also found in
         <PERMANENT>)
WARNING: Using <elevation@user1>
WARNING: 'cellhd/elevation' was found in more mapsets (also found in
         <PERMANENT>)
WARNING: Using <elevation@user1>
WARNING: 'cellhd/elevation' was found in more mapsets (also found in
         <PERMANENT>)
WARNING: Using <elevation@user1>

==> same thing

Creating BIL support files...
Exporting raster as floating values (bytes=4)
 100%

thanks
Markus

_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats
Reply | Threaded
Open this post in threaded view
|

Re: wish: less verbose messages in rgrass7

RKrug
Markus Neteler <[hidden email]> writes:

> Hi,
>
> today we used "rgrass7" on Windows (and I made some tests on Linux, too).

Hi Markus,

thanks for reporting.

>
> I was wondering about a few warnings which might be suppressed to avoid
> user confusion:
>
>
> ######## Windows: calling GRASS 7.1 from R session
>
>> library(rgrass7)
> Loading required package: sp
> Loading required package: XML
> GRASS GIS interface loaded with GRASS version: (GRASS not running)
> Warning messages:
> 1: package ‘rgrass7’ was built under R version 3.2.2
> 2: package ‘sp’ was built under R version 3.2.2
> 3: package ‘XML’ was built under R version 3.2.2
>
>> initGRASS(gisBase = "C:/OSGeo4W/apps/grass/grass-7.1.svn",
> + gisDbase = "C:/Users/marissa/GRASSdata/",
> + location = "CA", mapset = "Aegypti")
> Error in initGRASS(gisBase = "C:/OSGeo4W/apps/grass/grass-7.1.svn",
> gisDbase = "C:/Users/marissa/GRASSdata/",  :
>   A GISRC file already exists; to override, set override=TRUE
>
>
> ==> the last sentence is not quite clear. Perhaps change to
I agree with the first part of the sentence.

>
> "A GISRC file already exists (the GRASS GIS mapset is already in use); to
> override, set override=TRUE"

I don't think this is true. I have regularly to use #override=TRUE# even
though I definitely use the mapset. I rather think that the GISRC is not
cleaned up after finishing in grass in R.

This raises the question: if GISRC is created, should it be deleted,
i.e. should there be a function

  closeGRASS()

which is doing the cleanup (or is it done and not working in my cases)?

Rather change it to:

--8<---------------cut here---------------start------------->8--- "A
GISRC file already exists.
The GRASS GIS mapset might be already in use or the file has not been
deleted.
To override, set override=TRUE"
--8<---------------cuthere---------------end--------------->8---


>
>
>> initGRASS(gisBase = "C:/OSGeo4W/apps/grass/grass-7.1.svn",
> + gisDbase = "C:/Users/marissa/GRASSdata/",
> + location = "CA", mapset = "Aegypti",
> + override=TRUE)
> gisdbase    C:/Users/marissa/GRASSdata/
> location    CA
> mapset      Aegypti
> rows        265
> columns     230
> north       452000
> south       -608000
> west        -376000
> east        544000
> nsres       4000
> ewres       4000
> projection  +proj=aea +lat_1=34 +lat_2=40.5 +lat_0=0 +lon_0=-120 +x_0=0
> +y_0=-4000000 +no_defs +a=6378137 +rf=298.257222101
> +towgs84=0.000,0.000,0.000 +to_meter=1
> Warning message:
> In dir.create(gisDbase) : 'C:\Users\marissa\GRASSdata' already exists
>
> ==> the last warning is not clear to me. If I set override=TRUE, I refer to
> the mapset's gislock, hence the dir.create(gisDbase should not be done at
> all. Is it a bug?
Strange.

I just looked in the code of initGRASS() and all dir.create(gisDbase) are
in

,----
| if (!file.exists(gisDbase)) dir.create(gisDbase)
`----

statements. Maybe I am missing something? Could you set

--8<---------------cut here---------------start------------->8---
option(warn=2)
--8<---------------cut here---------------end--------------->8---

before running the code again and give a traceback?


>
>
> ############## Linux
>
>> ncdata <- readRAST("elevation")
> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>          <PERMANENT>)
> WARNING: Using <elevation@user1>
> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>          <PERMANENT>)
> WARNING: Using <elevation@user1>
> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>          <PERMANENT>)
> WARNING: Using <elevation@user1>
>
> ==> these warning make probably sense in a GRASS session but IMHO here
> less. They could be suppressed with --q in the respective GRASS module
> call.
Agreed - but very useful for debugging.

--q could could be added into the options of the rgrass7 package?

>
>
> Creating BIL support files...
> Exporting raster as floating values (bytes=4)
>  100%
> Warning messages:
> 1: In execGRASS("r.info", flags = "g", map = vname[i], intern = TRUE,  :
>   The command:
> r.info -g map=elevation
> produced at least one warning during execution:
> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>          <PERMANENT>)
> WARNING: Using <elevation@user1>
> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>          <PERMANENT>)
> WARNING: Using <elevation@user1>
> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>          <PERMANENT>)
> WARNING: Using <elevation@user1>
>
> ==> here it is, I suggest to use r.info --q
This should be optional - for debugging, these warnings might be crucial.

>
> 2: In execGRASS("r.info", flags = "r", map = vname[i], intern = TRUE,  :
>   The command:
> r.info -r map=elevation
> produced at least one warning during execution:
> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>          <PERMANENT>)
> WARNING: Using <elevation@user1>
> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>          <PERMANENT>)
> WARNING: Using <elevation@user1>
> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>          <PERMANENT>)
> WARNING: Using <elevation@user1>
>
> ==> same thing
No - If I use execGRASS() I know grass (hopefully...) and I can specify
--q if I want it.
The execGRASS must not add any flags or arguments which make the
commands differ from the GRASS versions.

>
> 3: In execGRASS("r.out.bin", flags = rOutBinFlags, input = vname[i],  :
>   The command:
> r.out.bin -b -f input=elevation
> output=/home/neteler/grassdata/nc_spm_08_grass7/user1/.tmp/pgis_north/elevation
> bytes=4 null=54
> produced at least one warning during execution:
> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>          <PERMANENT>)
> WARNING: Using <elevation@user1>
> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>          <PERMANENT>)
> WARNING: Using <elevation@user1>
> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>          <PERMANENT>)
> WARNING: Using <elevation@user1>
>
> ==> same thing
Should be using a new rgrass7 option for --q.

Cheers,

Rainer

>
> Creating BIL support files...
> Exporting raster as floating values (bytes=4)
>  100%
>
> thanks
> Markus
> _______________________________________________
> grass-stats mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/grass-stats
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      [hidden email]

Skype:      RMkrug

PGP: 0x0F52F982

_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats

signature.asc (490 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: wish: less verbose messages in rgrass7

Roger Bivand
On Thu, 10 Sep 2015, Rainer M Krug wrote:

> Markus Neteler <[hidden email]> writes:
>
>> Hi,
>>
>> today we used "rgrass7" on Windows (and I made some tests on Linux, too).
>
> Hi Markus,
>
> thanks for reporting.
>
>>
>> I was wondering about a few warnings which might be suppressed to avoid
>> user confusion:
Hi,

The confusion is probably coming from the use duality. If a location and
mapset already exists, the (much) prefered route is to run R inside GRASS
- start R from the GRASS console or similar. Then GISRC etc. are handled
in the correct way by GRASS itself.

If there is no location, and the location/mapset will be created on a
throw-away basis in the R temporary directory or elsewhere outside
GISDBASE, initGRASS() is a sensible choice, because it gives access to
GRASS tools - running GRASS inside R.

Here GRASS is being run inside R in relation to an existing
location/mapset using initGRASS(), which by design doesn't know anything
about locking etc.; it expects to throw the location away when R exits
(deleting the temporary directory if owned by R - mileage may vary on
Windows).

Should we tell users not to do something that isn't very sensible, or
change initGRASS to know much more about a running GRASS instance?

I prefer the former - for non-advanced users:

1) if the GRASS location/mapset is only a throwaway one, use initGRASS()
and run GRASS inside R;

2) if you already have a GRASS location/mapset, use R inside GRASS and do
not use initGRASS().

Advanced users can make their own choices.

Warnings should IMHO never be hidden - I don't agree that not knowing is
ever helpful.

I don't have time to look at this now, I can look in a couple of weeks'
time maybe.

Best wishes,

Roger

>>
>>
>> ######## Windows: calling GRASS 7.1 from R session
>>
>>> library(rgrass7)
>> Loading required package: sp
>> Loading required package: XML
>> GRASS GIS interface loaded with GRASS version: (GRASS not running)
>> Warning messages:
>> 1: package ‘rgrass7’ was built under R version 3.2.2
>> 2: package ‘sp’ was built under R version 3.2.2
>> 3: package ‘XML’ was built under R version 3.2.2
>>
>>> initGRASS(gisBase = "C:/OSGeo4W/apps/grass/grass-7.1.svn",
>> + gisDbase = "C:/Users/marissa/GRASSdata/",
>> + location = "CA", mapset = "Aegypti")
>> Error in initGRASS(gisBase = "C:/OSGeo4W/apps/grass/grass-7.1.svn",
>> gisDbase = "C:/Users/marissa/GRASSdata/",  :
>>   A GISRC file already exists; to override, set override=TRUE
>>
>>
>> ==> the last sentence is not quite clear. Perhaps change to
>
> I agree with the first part of the sentence.
>
>>
>> "A GISRC file already exists (the GRASS GIS mapset is already in use); to
>> override, set override=TRUE"
>
> I don't think this is true. I have regularly to use #override=TRUE# even
> though I definitely use the mapset. I rather think that the GISRC is not
> cleaned up after finishing in grass in R.
>
> This raises the question: if GISRC is created, should it be deleted,
> i.e. should there be a function
>
>  closeGRASS()
>
> which is doing the cleanup (or is it done and not working in my cases)?
>
> Rather change it to:
>
> --8<---------------cut here---------------start------------->8--- "A
> GISRC file already exists.
> The GRASS GIS mapset might be already in use or the file has not been
> deleted.
> To override, set override=TRUE"
> --8<---------------cuthere---------------end--------------->8---
>
>
>>
>>
>>> initGRASS(gisBase = "C:/OSGeo4W/apps/grass/grass-7.1.svn",
>> + gisDbase = "C:/Users/marissa/GRASSdata/",
>> + location = "CA", mapset = "Aegypti",
>> + override=TRUE)
>> gisdbase    C:/Users/marissa/GRASSdata/
>> location    CA
>> mapset      Aegypti
>> rows        265
>> columns     230
>> north       452000
>> south       -608000
>> west        -376000
>> east        544000
>> nsres       4000
>> ewres       4000
>> projection  +proj=aea +lat_1=34 +lat_2=40.5 +lat_0=0 +lon_0=-120 +x_0=0
>> +y_0=-4000000 +no_defs +a=6378137 +rf=298.257222101
>> +towgs84=0.000,0.000,0.000 +to_meter=1
>> Warning message:
>> In dir.create(gisDbase) : 'C:\Users\marissa\GRASSdata' already exists
>>
>> ==> the last warning is not clear to me. If I set override=TRUE, I refer to
>> the mapset's gislock, hence the dir.create(gisDbase should not be done at
>> all. Is it a bug?
>
> Strange.
>
> I just looked in the code of initGRASS() and all dir.create(gisDbase) are
> in
>
> ,----
> | if (!file.exists(gisDbase)) dir.create(gisDbase)
> `----
>
> statements. Maybe I am missing something? Could you set
>
> --8<---------------cut here---------------start------------->8---
> option(warn=2)
> --8<---------------cut here---------------end--------------->8---
>
> before running the code again and give a traceback?
>
>
>>
>>
>> ############## Linux
>>
>>> ncdata <- readRAST("elevation")
>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>          <PERMANENT>)
>> WARNING: Using <elevation@user1>
>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>          <PERMANENT>)
>> WARNING: Using <elevation@user1>
>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>          <PERMANENT>)
>> WARNING: Using <elevation@user1>
>>
>> ==> these warning make probably sense in a GRASS session but IMHO here
>> less. They could be suppressed with --q in the respective GRASS module
>> call.
>
> Agreed - but very useful for debugging.
>
> --q could could be added into the options of the rgrass7 package?
>
>>
>>
>> Creating BIL support files...
>> Exporting raster as floating values (bytes=4)
>>  100%
>> Warning messages:
>> 1: In execGRASS("r.info", flags = "g", map = vname[i], intern = TRUE,  :
>>   The command:
>> r.info -g map=elevation
>> produced at least one warning during execution:
>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>          <PERMANENT>)
>> WARNING: Using <elevation@user1>
>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>          <PERMANENT>)
>> WARNING: Using <elevation@user1>
>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>          <PERMANENT>)
>> WARNING: Using <elevation@user1>
>>
>> ==> here it is, I suggest to use r.info --q
>
> This should be optional - for debugging, these warnings might be crucial.
>
>>
>> 2: In execGRASS("r.info", flags = "r", map = vname[i], intern = TRUE,  :
>>   The command:
>> r.info -r map=elevation
>> produced at least one warning during execution:
>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>          <PERMANENT>)
>> WARNING: Using <elevation@user1>
>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>          <PERMANENT>)
>> WARNING: Using <elevation@user1>
>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>          <PERMANENT>)
>> WARNING: Using <elevation@user1>
>>
>> ==> same thing
>
> No - If I use execGRASS() I know grass (hopefully...) and I can specify
> --q if I want it.
> The execGRASS must not add any flags or arguments which make the
> commands differ from the GRASS versions.
>
>>
>> 3: In execGRASS("r.out.bin", flags = rOutBinFlags, input = vname[i],  :
>>   The command:
>> r.out.bin -b -f input=elevation
>> output=/home/neteler/grassdata/nc_spm_08_grass7/user1/.tmp/pgis_north/elevation
>> bytes=4 null=54
>> produced at least one warning during execution:
>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>          <PERMANENT>)
>> WARNING: Using <elevation@user1>
>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>          <PERMANENT>)
>> WARNING: Using <elevation@user1>
>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>          <PERMANENT>)
>> WARNING: Using <elevation@user1>
>>
>> ==> same thing
>
> Should be using a new rgrass7 option for --q.
>
> Cheers,
>
> Rainer
>
>>
>> Creating BIL support files...
>> Exporting raster as floating values (bytes=4)
>>  100%
>>
>> thanks
>> Markus
>> _______________________________________________
>> grass-stats mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/grass-stats
>
>
--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; fax +47 55 95 91 00
e-mail: [hidden email]

_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
Reply | Threaded
Open this post in threaded view
|

Re: wish: less verbose messages in rgrass7

RKrug
Roger Bivand <[hidden email]> writes:

> On Thu, 10 Sep 2015, Rainer M Krug wrote:
>
>> Markus Neteler <[hidden email]> writes:
>>
>>> Hi,
>>>
>>> today we used "rgrass7" on Windows (and I made some tests on Linux, too).
>>
>> Hi Markus,
>>
>> thanks for reporting.
>>
>>>
>>> I was wondering about a few warnings which might be suppressed to avoid
>>> user confusion:
>
> Hi,
>
> The confusion is probably coming from the use duality. If a location
> and mapset already exists, the (much) prefered route is to run R
> inside GRASS - start R from the GRASS console or similar. Then GISRC
> etc. are handled in the correct way by GRASS itself.
>
> If there is no location, and the location/mapset will be created on a
> throw-away basis in the R temporary directory or elsewhere outside
> GISDBASE, initGRASS() is a sensible choice, because it gives access to
> GRASS tools - running GRASS inside R.
>
> Here GRASS is being run inside R in relation to an existing
> location/mapset using initGRASS(), which by design doesn't know
> anything about locking etc.; it expects to throw the location away
> when R exits (deleting the temporary directory if owned by R - mileage
> may vary on Windows).
>
> Should we tell users not to do something that isn't very sensible, or
> change initGRASS to know much more about a running GRASS instance?
>
> I prefer the former - for non-advanced users:
>
> 1) if the GRASS location/mapset is only a throwaway one, use
> initGRASS() and run GRASS inside R;
>
> 2) if you already have a GRASS location/mapset, use R inside GRASS and
> do not use initGRASS().
>
> Advanced users can make their own choices.
That is one major problem in rgrass: that one is encouraged to run R in
GRASS to use an existing mapset.

I have no idea how python and other languages which have a GRASS
interface do it, but I don't think that they should be run in GRASS. If
I use R, GRASS is a kind of a library, about which I do not want to
care.

So the way forward should be to make the "GRASS in R" scenario the main
way of using GRASS in R.
This will become much easier in 7.1 with the --exec argument. See

--8<---------------cut here---------------start------------->8---
https://lists.osgeo.org/pipermail/grass-user/2015-June/072515.html
https://grass.osgeo.org/grass71/manuals/grass7.html#exec-interface-example
--8<---------------cut here---------------end--------------->8---

for how it looks at the moment.

I wanted to look into using this approach for rgrass71 but did not
manage so far to look at it.

This is not to say that the "running R in GRASS" scenario is not
needed - but I see that one as using R from GRASS to do spatial analysis
and continue afterwards in GRASS - so a little bit like R as a tool in
GRASS, while the other is GRASS a tool in R.

In the long run, these are two quite different usage scenarios which
might even diverge over time in two different packages.

>
> Warnings should IMHO never be hidden - I don't agree that not knowing
> is ever helpful.

Not helpful - but when writing simulations (as I did) the warnings will
clutter the output and if I know the warnings, I simply would like to
have the option to silence them.

Apart from that, I think that particular warning would be a case for a
"verbose" output in GRASS as it is looking for something I did not tell
it to (look in PERMANENT when the map exists in the mapset I am in).

As in GRASS, I think there should be an option to silence the warnings,
specifically in the case of the commands in rgrass - that was what I
meant bu introducing an additional option (like e.g. useGDAL), so that
they can be silenced if necessary.

execGRASS should always do / show what GRASS would do / show when the
command is executed.

>
> I don't have time to look at this now, I can look in a couple of
> weeks' time maybe.
>
> Best wishes,
>
> Roger
>
>>>
>>>
>>> ######## Windows: calling GRASS 7.1 from R session
>>>
>>>> library(rgrass7)
>>> Loading required package: sp
>>> Loading required package: XML
>>> GRASS GIS interface loaded with GRASS version: (GRASS not running)
>>> Warning messages:
>>> 1: package ‘rgrass7’ was built under R version 3.2.2
>>> 2: package ‘sp’ was built under R version 3.2.2
>>> 3: package ‘XML’ was built under R version 3.2.2
>>>
>>>> initGRASS(gisBase = "C:/OSGeo4W/apps/grass/grass-7.1.svn",
>>> + gisDbase = "C:/Users/marissa/GRASSdata/",
>>> + location = "CA", mapset = "Aegypti")
>>> Error in initGRASS(gisBase = "C:/OSGeo4W/apps/grass/grass-7.1.svn",
>>> gisDbase = "C:/Users/marissa/GRASSdata/",  :
>>>   A GISRC file already exists; to override, set override=TRUE
>>>
>>>
>>> ==> the last sentence is not quite clear. Perhaps change to
>>
>> I agree with the first part of the sentence.
>>
>>>
>>> "A GISRC file already exists (the GRASS GIS mapset is already in use); to
>>> override, set override=TRUE"
>>
>> I don't think this is true. I have regularly to use #override=TRUE# even
>> though I definitely use the mapset. I rather think that the GISRC is not
>> cleaned up after finishing in grass in R.
>>
>> This raises the question: if GISRC is created, should it be deleted,
>> i.e. should there be a function
>>
>>  closeGRASS()
>>
>> which is doing the cleanup (or is it done and not working in my cases)?
>>
>> Rather change it to:
>>
>> --8<---------------cut here---------------start------------->8--- "A
>> GISRC file already exists.
>> The GRASS GIS mapset might be already in use or the file has not been
>> deleted.
>> To override, set override=TRUE"
>> --8<---------------cuthere---------------end--------------->8---
>>
>>
>>>
>>>
>>>> initGRASS(gisBase = "C:/OSGeo4W/apps/grass/grass-7.1.svn",
>>> + gisDbase = "C:/Users/marissa/GRASSdata/",
>>> + location = "CA", mapset = "Aegypti",
>>> + override=TRUE)
>>> gisdbase    C:/Users/marissa/GRASSdata/
>>> location    CA
>>> mapset      Aegypti
>>> rows        265
>>> columns     230
>>> north       452000
>>> south       -608000
>>> west        -376000
>>> east        544000
>>> nsres       4000
>>> ewres       4000
>>> projection  +proj=aea +lat_1=34 +lat_2=40.5 +lat_0=0 +lon_0=-120 +x_0=0
>>> +y_0=-4000000 +no_defs +a=6378137 +rf=298.257222101
>>> +towgs84=0.000,0.000,0.000 +to_meter=1
>>> Warning message:
>>> In dir.create(gisDbase) : 'C:\Users\marissa\GRASSdata' already exists
>>>
>>> ==> the last warning is not clear to me. If I set override=TRUE, I refer to
>>> the mapset's gislock, hence the dir.create(gisDbase should not be done at
>>> all. Is it a bug?
>>
>> Strange.
>>
>> I just looked in the code of initGRASS() and all dir.create(gisDbase) are
>> in
>>
>> ,----
>> | if (!file.exists(gisDbase)) dir.create(gisDbase)
>> `----
>>
>> statements. Maybe I am missing something? Could you set
>>
>> --8<---------------cut here---------------start------------->8---
>> option(warn=2)
>> --8<---------------cut here---------------end--------------->8---
>>
>> before running the code again and give a traceback?
>>
>>
>>>
>>>
>>> ############## Linux
>>>
>>>> ncdata <- readRAST("elevation")
>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>          <PERMANENT>)
>>> WARNING: Using <elevation@user1>
>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>          <PERMANENT>)
>>> WARNING: Using <elevation@user1>
>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>          <PERMANENT>)
>>> WARNING: Using <elevation@user1>
>>>
>>> ==> these warning make probably sense in a GRASS session but IMHO here
>>> less. They could be suppressed with --q in the respective GRASS module
>>> call.
>>
>> Agreed - but very useful for debugging.
>>
>> --q could could be added into the options of the rgrass7 package?
>>
>>>
>>>
>>> Creating BIL support files...
>>> Exporting raster as floating values (bytes=4)
>>>  100%
>>> Warning messages:
>>> 1: In execGRASS("r.info", flags = "g", map = vname[i], intern = TRUE,  :
>>>   The command:
>>> r.info -g map=elevation
>>> produced at least one warning during execution:
>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>          <PERMANENT>)
>>> WARNING: Using <elevation@user1>
>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>          <PERMANENT>)
>>> WARNING: Using <elevation@user1>
>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>          <PERMANENT>)
>>> WARNING: Using <elevation@user1>
>>>
>>> ==> here it is, I suggest to use r.info --q
>>
>> This should be optional - for debugging, these warnings might be crucial.
>>
>>>
>>> 2: In execGRASS("r.info", flags = "r", map = vname[i], intern = TRUE,  :
>>>   The command:
>>> r.info -r map=elevation
>>> produced at least one warning during execution:
>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>          <PERMANENT>)
>>> WARNING: Using <elevation@user1>
>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>          <PERMANENT>)
>>> WARNING: Using <elevation@user1>
>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>          <PERMANENT>)
>>> WARNING: Using <elevation@user1>
>>>
>>> ==> same thing
>>
>> No - If I use execGRASS() I know grass (hopefully...) and I can specify
>> --q if I want it.
>> The execGRASS must not add any flags or arguments which make the
>> commands differ from the GRASS versions.
>>
>>>
>>> 3: In execGRASS("r.out.bin", flags = rOutBinFlags, input = vname[i],  :
>>>   The command:
>>> r.out.bin -b -f input=elevation
>>> output=/home/neteler/grassdata/nc_spm_08_grass7/user1/.tmp/pgis_north/elevation
>>> bytes=4 null=54
>>> produced at least one warning during execution:
>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>          <PERMANENT>)
>>> WARNING: Using <elevation@user1>
>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>          <PERMANENT>)
>>> WARNING: Using <elevation@user1>
>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>          <PERMANENT>)
>>> WARNING: Using <elevation@user1>
>>>
>>> ==> same thing
>>
>> Should be using a new rgrass7 option for --q.
>>
>> Cheers,
>>
>> Rainer
>>
>>>
>>> Creating BIL support files...
>>> Exporting raster as floating values (bytes=4)
>>>  100%
>>>
>>> thanks
>>> Markus
>>> _______________________________________________
>>> grass-stats mailing list
>>> [hidden email]
>>> http://lists.osgeo.org/mailman/listinfo/grass-stats
>>
>>
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      [hidden email]

Skype:      RMkrug

PGP: 0x0F52F982

_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats

signature.asc (490 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: wish: less verbose messages in rgrass7

Roger Bivand
On Thu, 10 Sep 2015, Rainer M Krug wrote:

> Roger Bivand <[hidden email]> writes:
>
>> On Thu, 10 Sep 2015, Rainer M Krug wrote:
>>
>>> Markus Neteler <[hidden email]> writes:
>>>
>>>> Hi,
>>>>
>>>> today we used "rgrass7" on Windows (and I made some tests on Linux, too).
>>>
>>> Hi Markus,
>>>
>>> thanks for reporting.
>>>
>>>>
>>>> I was wondering about a few warnings which might be suppressed to avoid
>>>> user confusion:
>>
>> Hi,
>>
>> The confusion is probably coming from the use duality. If a location
>> and mapset already exists, the (much) prefered route is to run R
>> inside GRASS - start R from the GRASS console or similar. Then GISRC
>> etc. are handled in the correct way by GRASS itself.
>>
>> If there is no location, and the location/mapset will be created on a
>> throw-away basis in the R temporary directory or elsewhere outside
>> GISDBASE, initGRASS() is a sensible choice, because it gives access to
>> GRASS tools - running GRASS inside R.
>>
>> Here GRASS is being run inside R in relation to an existing
>> location/mapset using initGRASS(), which by design doesn't know
>> anything about locking etc.; it expects to throw the location away
>> when R exits (deleting the temporary directory if owned by R - mileage
>> may vary on Windows).
>>
>> Should we tell users not to do something that isn't very sensible, or
>> change initGRASS to know much more about a running GRASS instance?
>>
>> I prefer the former - for non-advanced users:
>>
>> 1) if the GRASS location/mapset is only a throwaway one, use
>> initGRASS() and run GRASS inside R;
>>
>> 2) if you already have a GRASS location/mapset, use R inside GRASS and
>> do not use initGRASS().
>>
>> Advanced users can make their own choices.
>
> That is one major problem in rgrass: that one is encouraged to run R in
> GRASS to use an existing mapset.
>
> I have no idea how python and other languages which have a GRASS
> interface do it, but I don't think that they should be run in GRASS. If
> I use R, GRASS is a kind of a library, about which I do not want to
> care.
>
> So the way forward should be to make the "GRASS in R" scenario the main
> way of using GRASS in R.
> This will become much easier in 7.1 with the --exec argument. See
>
> --8<---------------cut here---------------start------------->8---
> https://lists.osgeo.org/pipermail/grass-user/2015-June/072515.html
> https://grass.osgeo.org/grass71/manuals/grass7.html#exec-interface-example
> --8<---------------cut here---------------end--------------->8---
>
> for how it looks at the moment.
>
> I wanted to look into using this approach for rgrass71 but did not
> manage so far to look at it.
>
> This is not to say that the "running R in GRASS" scenario is not
> needed - but I see that one as using R from GRASS to do spatial analysis
> and continue afterwards in GRASS - so a little bit like R as a tool in
> GRASS, while the other is GRASS a tool in R.
>
> In the long run, these are two quite different usage scenarios which
> might even diverge over time in two different packages.
>
>>
>> Warnings should IMHO never be hidden - I don't agree that not knowing
>> is ever helpful.
>
> Not helpful - but when writing simulations (as I did) the warnings will
> clutter the output and if I know the warnings, I simply would like to
> have the option to silence them.
Maybe use options("warn"), and add checking within doGRASS() to add --q if
options("warn") takes a suitable value - rather than an extra argument?
Then it only needs setting once?

Roger

>
> Apart from that, I think that particular warning would be a case for a
> "verbose" output in GRASS as it is looking for something I did not tell
> it to (look in PERMANENT when the map exists in the mapset I am in).
>
> As in GRASS, I think there should be an option to silence the warnings,
> specifically in the case of the commands in rgrass - that was what I
> meant bu introducing an additional option (like e.g. useGDAL), so that
> they can be silenced if necessary.
>
> execGRASS should always do / show what GRASS would do / show when the
> command is executed.
>
>>
>> I don't have time to look at this now, I can look in a couple of
>> weeks' time maybe.
>>
>> Best wishes,
>>
>> Roger
>>
>>>>
>>>>
>>>> ######## Windows: calling GRASS 7.1 from R session
>>>>
>>>>> library(rgrass7)
>>>> Loading required package: sp
>>>> Loading required package: XML
>>>> GRASS GIS interface loaded with GRASS version: (GRASS not running)
>>>> Warning messages:
>>>> 1: package ‘rgrass7’ was built under R version 3.2.2
>>>> 2: package ‘sp’ was built under R version 3.2.2
>>>> 3: package ‘XML’ was built under R version 3.2.2
>>>>
>>>>> initGRASS(gisBase = "C:/OSGeo4W/apps/grass/grass-7.1.svn",
>>>> + gisDbase = "C:/Users/marissa/GRASSdata/",
>>>> + location = "CA", mapset = "Aegypti")
>>>> Error in initGRASS(gisBase = "C:/OSGeo4W/apps/grass/grass-7.1.svn",
>>>> gisDbase = "C:/Users/marissa/GRASSdata/",  :
>>>>   A GISRC file already exists; to override, set override=TRUE
>>>>
>>>>
>>>> ==> the last sentence is not quite clear. Perhaps change to
>>>
>>> I agree with the first part of the sentence.
>>>
>>>>
>>>> "A GISRC file already exists (the GRASS GIS mapset is already in use); to
>>>> override, set override=TRUE"
>>>
>>> I don't think this is true. I have regularly to use #override=TRUE# even
>>> though I definitely use the mapset. I rather think that the GISRC is not
>>> cleaned up after finishing in grass in R.
>>>
>>> This raises the question: if GISRC is created, should it be deleted,
>>> i.e. should there be a function
>>>
>>>  closeGRASS()
>>>
>>> which is doing the cleanup (or is it done and not working in my cases)?
>>>
>>> Rather change it to:
>>>
>>> --8<---------------cut here---------------start------------->8--- "A
>>> GISRC file already exists.
>>> The GRASS GIS mapset might be already in use or the file has not been
>>> deleted.
>>> To override, set override=TRUE"
>>> --8<---------------cuthere---------------end--------------->8---
>>>
>>>
>>>>
>>>>
>>>>> initGRASS(gisBase = "C:/OSGeo4W/apps/grass/grass-7.1.svn",
>>>> + gisDbase = "C:/Users/marissa/GRASSdata/",
>>>> + location = "CA", mapset = "Aegypti",
>>>> + override=TRUE)
>>>> gisdbase    C:/Users/marissa/GRASSdata/
>>>> location    CA
>>>> mapset      Aegypti
>>>> rows        265
>>>> columns     230
>>>> north       452000
>>>> south       -608000
>>>> west        -376000
>>>> east        544000
>>>> nsres       4000
>>>> ewres       4000
>>>> projection  +proj=aea +lat_1=34 +lat_2=40.5 +lat_0=0 +lon_0=-120 +x_0=0
>>>> +y_0=-4000000 +no_defs +a=6378137 +rf=298.257222101
>>>> +towgs84=0.000,0.000,0.000 +to_meter=1
>>>> Warning message:
>>>> In dir.create(gisDbase) : 'C:\Users\marissa\GRASSdata' already exists
>>>>
>>>> ==> the last warning is not clear to me. If I set override=TRUE, I refer to
>>>> the mapset's gislock, hence the dir.create(gisDbase should not be done at
>>>> all. Is it a bug?
>>>
>>> Strange.
>>>
>>> I just looked in the code of initGRASS() and all dir.create(gisDbase) are
>>> in
>>>
>>> ,----
>>> | if (!file.exists(gisDbase)) dir.create(gisDbase)
>>> `----
>>>
>>> statements. Maybe I am missing something? Could you set
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> option(warn=2)
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> before running the code again and give a traceback?
>>>
>>>
>>>>
>>>>
>>>> ############## Linux
>>>>
>>>>> ncdata <- readRAST("elevation")
>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>>          <PERMANENT>)
>>>> WARNING: Using <elevation@user1>
>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>>          <PERMANENT>)
>>>> WARNING: Using <elevation@user1>
>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>>          <PERMANENT>)
>>>> WARNING: Using <elevation@user1>
>>>>
>>>> ==> these warning make probably sense in a GRASS session but IMHO here
>>>> less. They could be suppressed with --q in the respective GRASS module
>>>> call.
>>>
>>> Agreed - but very useful for debugging.
>>>
>>> --q could could be added into the options of the rgrass7 package?
>>>
>>>>
>>>>
>>>> Creating BIL support files...
>>>> Exporting raster as floating values (bytes=4)
>>>>  100%
>>>> Warning messages:
>>>> 1: In execGRASS("r.info", flags = "g", map = vname[i], intern = TRUE,  :
>>>>   The command:
>>>> r.info -g map=elevation
>>>> produced at least one warning during execution:
>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>>          <PERMANENT>)
>>>> WARNING: Using <elevation@user1>
>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>>          <PERMANENT>)
>>>> WARNING: Using <elevation@user1>
>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>>          <PERMANENT>)
>>>> WARNING: Using <elevation@user1>
>>>>
>>>> ==> here it is, I suggest to use r.info --q
>>>
>>> This should be optional - for debugging, these warnings might be crucial.
>>>
>>>>
>>>> 2: In execGRASS("r.info", flags = "r", map = vname[i], intern = TRUE,  :
>>>>   The command:
>>>> r.info -r map=elevation
>>>> produced at least one warning during execution:
>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>>          <PERMANENT>)
>>>> WARNING: Using <elevation@user1>
>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>>          <PERMANENT>)
>>>> WARNING: Using <elevation@user1>
>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>>          <PERMANENT>)
>>>> WARNING: Using <elevation@user1>
>>>>
>>>> ==> same thing
>>>
>>> No - If I use execGRASS() I know grass (hopefully...) and I can specify
>>> --q if I want it.
>>> The execGRASS must not add any flags or arguments which make the
>>> commands differ from the GRASS versions.
>>>
>>>>
>>>> 3: In execGRASS("r.out.bin", flags = rOutBinFlags, input = vname[i],  :
>>>>   The command:
>>>> r.out.bin -b -f input=elevation
>>>> output=/home/neteler/grassdata/nc_spm_08_grass7/user1/.tmp/pgis_north/elevation
>>>> bytes=4 null=54
>>>> produced at least one warning during execution:
>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>>          <PERMANENT>)
>>>> WARNING: Using <elevation@user1>
>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>>          <PERMANENT>)
>>>> WARNING: Using <elevation@user1>
>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>>          <PERMANENT>)
>>>> WARNING: Using <elevation@user1>
>>>>
>>>> ==> same thing
>>>
>>> Should be using a new rgrass7 option for --q.
>>>
>>> Cheers,
>>>
>>> Rainer
>>>
>>>>
>>>> Creating BIL support files...
>>>> Exporting raster as floating values (bytes=4)
>>>>  100%
>>>>
>>>> thanks
>>>> Markus
>>>> _______________________________________________
>>>> grass-stats mailing list
>>>> [hidden email]
>>>> http://lists.osgeo.org/mailman/listinfo/grass-stats
>>>
>>>
>
>
--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; fax +47 55 95 91 00
e-mail: [hidden email]

_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
Reply | Threaded
Open this post in threaded view
|

Re: wish: less verbose messages in rgrass7

RKrug
Roger Bivand <[hidden email]> writes:

> On Thu, 10 Sep 2015, Rainer M Krug wrote:
>
>> Roger Bivand <[hidden email]> writes:
>>
>>> On Thu, 10 Sep 2015, Rainer M Krug wrote:
>>>
>>>> Markus Neteler <[hidden email]> writes:
>>>>
>>>>> Hi,
>>>>>
>>>>> today we used "rgrass7" on Windows (and I made some tests on Linux, too).
>>>>
>>>> Hi Markus,
>>>>
>>>> thanks for reporting.
>>>>
>>>>>
>>>>> I was wondering about a few warnings which might be suppressed to avoid
>>>>> user confusion:
>>>
>>> Hi,
>>>
>>> The confusion is probably coming from the use duality. If a location
>>> and mapset already exists, the (much) prefered route is to run R
>>> inside GRASS - start R from the GRASS console or similar. Then GISRC
>>> etc. are handled in the correct way by GRASS itself.
>>>
>>> If there is no location, and the location/mapset will be created on a
>>> throw-away basis in the R temporary directory or elsewhere outside
>>> GISDBASE, initGRASS() is a sensible choice, because it gives access to
>>> GRASS tools - running GRASS inside R.
>>>
>>> Here GRASS is being run inside R in relation to an existing
>>> location/mapset using initGRASS(), which by design doesn't know
>>> anything about locking etc.; it expects to throw the location away
>>> when R exits (deleting the temporary directory if owned by R - mileage
>>> may vary on Windows).
>>>
>>> Should we tell users not to do something that isn't very sensible, or
>>> change initGRASS to know much more about a running GRASS instance?
>>>
>>> I prefer the former - for non-advanced users:
>>>
>>> 1) if the GRASS location/mapset is only a throwaway one, use
>>> initGRASS() and run GRASS inside R;
>>>
>>> 2) if you already have a GRASS location/mapset, use R inside GRASS and
>>> do not use initGRASS().
>>>
>>> Advanced users can make their own choices.
>>
>> That is one major problem in rgrass: that one is encouraged to run R in
>> GRASS to use an existing mapset.
>>
>> I have no idea how python and other languages which have a GRASS
>> interface do it, but I don't think that they should be run in GRASS. If
>> I use R, GRASS is a kind of a library, about which I do not want to
>> care.
>>
>> So the way forward should be to make the "GRASS in R" scenario the main
>> way of using GRASS in R.
>> This will become much easier in 7.1 with the --exec argument. See
>>
>> --8<---------------cut here---------------start------------->8---
>> https://lists.osgeo.org/pipermail/grass-user/2015-June/072515.html
>> https://grass.osgeo.org/grass71/manuals/grass7.html#exec-interface-example
>> --8<---------------cut here---------------end--------------->8---
>>
>> for how it looks at the moment.
>>
>> I wanted to look into using this approach for rgrass71 but did not
>> manage so far to look at it.
>>
>> This is not to say that the "running R in GRASS" scenario is not
>> needed - but I see that one as using R from GRASS to do spatial analysis
>> and continue afterwards in GRASS - so a little bit like R as a tool in
>> GRASS, while the other is GRASS a tool in R.
>>
>> In the long run, these are two quite different usage scenarios which
>> might even diverge over time in two different packages.
>>
>>>
>>> Warnings should IMHO never be hidden - I don't agree that not knowing
>>> is ever helpful.
>>
>> Not helpful - but when writing simulations (as I did) the warnings will
>> clutter the output and if I know the warnings, I simply would like to
>> have the option to silence them.
>
> Maybe use options("warn"), and add checking within doGRASS() to add
> --q if options("warn") takes a suitable value - rather than an extra
> argument? Then it only needs setting once?
Hm. I see options("warn") as a ind of last resort when nothing else
works, as all warnings are suppressed. I would suggest an additional
argument for the "toplevel" functions:

readRAST
writeRAST
readVECT
writeVECT

to get an additional argument

suppressGRASSwarnings

which would pass the --q flag to the calls to GRASS fro within these
functions.

This argument should be, as e.g. useGDAL, settable globally for all
calls to these functions.

This would be a much more fine grained solution as only GRASS warnings
would be suppressed and not R warnings.

As this is a cosmetical change, I would add it to the TODO for rgrass7
and implement it as soon as somebody has time.

Cheers,

Rainer

>
> Roger
>
>>
>> Apart from that, I think that particular warning would be a case for a
>> "verbose" output in GRASS as it is looking for something I did not tell
>> it to (look in PERMANENT when the map exists in the mapset I am in).
>>
>> As in GRASS, I think there should be an option to silence the warnings,
>> specifically in the case of the commands in rgrass - that was what I
>> meant bu introducing an additional option (like e.g. useGDAL), so that
>> they can be silenced if necessary.
>>
>> execGRASS should always do / show what GRASS would do / show when the
>> command is executed.
>>
>>>
>>> I don't have time to look at this now, I can look in a couple of
>>> weeks' time maybe.
>>>
>>> Best wishes,
>>>
>>> Roger
>>>
>>>>>
>>>>>
>>>>> ######## Windows: calling GRASS 7.1 from R session
>>>>>
>>>>>> library(rgrass7)
>>>>> Loading required package: sp
>>>>> Loading required package: XML
>>>>> GRASS GIS interface loaded with GRASS version: (GRASS not running)
>>>>> Warning messages:
>>>>> 1: package ‘rgrass7’ was built under R version 3.2.2
>>>>> 2: package ‘sp’ was built under R version 3.2.2
>>>>> 3: package ‘XML’ was built under R version 3.2.2
>>>>>
>>>>>> initGRASS(gisBase = "C:/OSGeo4W/apps/grass/grass-7.1.svn",
>>>>> + gisDbase = "C:/Users/marissa/GRASSdata/",
>>>>> + location = "CA", mapset = "Aegypti")
>>>>> Error in initGRASS(gisBase = "C:/OSGeo4W/apps/grass/grass-7.1.svn",
>>>>> gisDbase = "C:/Users/marissa/GRASSdata/",  :
>>>>>   A GISRC file already exists; to override, set override=TRUE
>>>>>
>>>>>
>>>>> ==> the last sentence is not quite clear. Perhaps change to
>>>>
>>>> I agree with the first part of the sentence.
>>>>
>>>>>
>>>>> "A GISRC file already exists (the GRASS GIS mapset is already in use); to
>>>>> override, set override=TRUE"
>>>>
>>>> I don't think this is true. I have regularly to use #override=TRUE# even
>>>> though I definitely use the mapset. I rather think that the GISRC is not
>>>> cleaned up after finishing in grass in R.
>>>>
>>>> This raises the question: if GISRC is created, should it be deleted,
>>>> i.e. should there be a function
>>>>
>>>>  closeGRASS()
>>>>
>>>> which is doing the cleanup (or is it done and not working in my cases)?
>>>>
>>>> Rather change it to:
>>>>
>>>> --8<---------------cut here---------------start------------->8--- "A
>>>> GISRC file already exists.
>>>> The GRASS GIS mapset might be already in use or the file has not been
>>>> deleted.
>>>> To override, set override=TRUE"
>>>> --8<---------------cuthere---------------end--------------->8---
>>>>
>>>>
>>>>>
>>>>>
>>>>>> initGRASS(gisBase = "C:/OSGeo4W/apps/grass/grass-7.1.svn",
>>>>> + gisDbase = "C:/Users/marissa/GRASSdata/",
>>>>> + location = "CA", mapset = "Aegypti",
>>>>> + override=TRUE)
>>>>> gisdbase    C:/Users/marissa/GRASSdata/
>>>>> location    CA
>>>>> mapset      Aegypti
>>>>> rows        265
>>>>> columns     230
>>>>> north       452000
>>>>> south       -608000
>>>>> west        -376000
>>>>> east        544000
>>>>> nsres       4000
>>>>> ewres       4000
>>>>> projection  +proj=aea +lat_1=34 +lat_2=40.5 +lat_0=0 +lon_0=-120 +x_0=0
>>>>> +y_0=-4000000 +no_defs +a=6378137 +rf=298.257222101
>>>>> +towgs84=0.000,0.000,0.000 +to_meter=1
>>>>> Warning message:
>>>>> In dir.create(gisDbase) : 'C:\Users\marissa\GRASSdata' already exists
>>>>>
>>>>> ==> the last warning is not clear to me. If I set override=TRUE, I refer to
>>>>> the mapset's gislock, hence the dir.create(gisDbase should not be done at
>>>>> all. Is it a bug?
>>>>
>>>> Strange.
>>>>
>>>> I just looked in the code of initGRASS() and all dir.create(gisDbase) are
>>>> in
>>>>
>>>> ,----
>>>> | if (!file.exists(gisDbase)) dir.create(gisDbase)
>>>> `----
>>>>
>>>> statements. Maybe I am missing something? Could you set
>>>>
>>>> --8<---------------cut here---------------start------------->8---
>>>> option(warn=2)
>>>> --8<---------------cut here---------------end--------------->8---
>>>>
>>>> before running the code again and give a traceback?
>>>>
>>>>
>>>>>
>>>>>
>>>>> ############## Linux
>>>>>
>>>>>> ncdata <- readRAST("elevation")
>>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>>>          <PERMANENT>)
>>>>> WARNING: Using <elevation@user1>
>>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>>>          <PERMANENT>)
>>>>> WARNING: Using <elevation@user1>
>>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>>>          <PERMANENT>)
>>>>> WARNING: Using <elevation@user1>
>>>>>
>>>>> ==> these warning make probably sense in a GRASS session but IMHO here
>>>>> less. They could be suppressed with --q in the respective GRASS module
>>>>> call.
>>>>
>>>> Agreed - but very useful for debugging.
>>>>
>>>> --q could could be added into the options of the rgrass7 package?
>>>>
>>>>>
>>>>>
>>>>> Creating BIL support files...
>>>>> Exporting raster as floating values (bytes=4)
>>>>>  100%
>>>>> Warning messages:
>>>>> 1: In execGRASS("r.info", flags = "g", map = vname[i], intern = TRUE,  :
>>>>>   The command:
>>>>> r.info -g map=elevation
>>>>> produced at least one warning during execution:
>>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>>>          <PERMANENT>)
>>>>> WARNING: Using <elevation@user1>
>>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>>>          <PERMANENT>)
>>>>> WARNING: Using <elevation@user1>
>>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>>>          <PERMANENT>)
>>>>> WARNING: Using <elevation@user1>
>>>>>
>>>>> ==> here it is, I suggest to use r.info --q
>>>>
>>>> This should be optional - for debugging, these warnings might be crucial.
>>>>
>>>>>
>>>>> 2: In execGRASS("r.info", flags = "r", map = vname[i], intern = TRUE,  :
>>>>>   The command:
>>>>> r.info -r map=elevation
>>>>> produced at least one warning during execution:
>>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>>>          <PERMANENT>)
>>>>> WARNING: Using <elevation@user1>
>>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>>>          <PERMANENT>)
>>>>> WARNING: Using <elevation@user1>
>>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>>>          <PERMANENT>)
>>>>> WARNING: Using <elevation@user1>
>>>>>
>>>>> ==> same thing
>>>>
>>>> No - If I use execGRASS() I know grass (hopefully...) and I can specify
>>>> --q if I want it.
>>>> The execGRASS must not add any flags or arguments which make the
>>>> commands differ from the GRASS versions.
>>>>
>>>>>
>>>>> 3: In execGRASS("r.out.bin", flags = rOutBinFlags, input = vname[i],  :
>>>>>   The command:
>>>>> r.out.bin -b -f input=elevation
>>>>> output=/home/neteler/grassdata/nc_spm_08_grass7/user1/.tmp/pgis_north/elevation
>>>>> bytes=4 null=54
>>>>> produced at least one warning during execution:
>>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>>>          <PERMANENT>)
>>>>> WARNING: Using <elevation@user1>
>>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>>>          <PERMANENT>)
>>>>> WARNING: Using <elevation@user1>
>>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>>>          <PERMANENT>)
>>>>> WARNING: Using <elevation@user1>
>>>>>
>>>>> ==> same thing
>>>>
>>>> Should be using a new rgrass7 option for --q.
>>>>
>>>> Cheers,
>>>>
>>>> Rainer
>>>>
>>>>>
>>>>> Creating BIL support files...
>>>>> Exporting raster as floating values (bytes=4)
>>>>>  100%
>>>>>
>>>>> thanks
>>>>> Markus
>>>>> _______________________________________________
>>>>> grass-stats mailing list
>>>>> [hidden email]
>>>>> http://lists.osgeo.org/mailman/listinfo/grass-stats
>>>>
>>>>
>>
>>
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      [hidden email]

Skype:      RMkrug

PGP: 0x0F52F982

_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats

signature.asc (490 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: wish: less verbose messages in rgrass7

wenzeslaus
In reply to this post by Markus Neteler

On Wed, Sep 9, 2015 at 5:35 PM, Markus Neteler <[hidden email]> wrote:
> ncdata <- readRAST("elevation")
WARNING: 'cellhd/elevation' was found in more mapsets (also found in
         <PERMANENT>)
WARNING: Using <elevation@user1>
WARNING: 'cellhd/elevation' was found in more mapsets (also found in
         <PERMANENT>)
WARNING: Using <elevation@user1>
WARNING: 'cellhd/elevation' was found in more mapsets (also found in
         <PERMANENT>)
WARNING: Using <elevation@user1>

==> these warning make probably sense in a GRASS session but IMHO here less. They could be suppressed with --q in the respective GRASS module call.

I don't a big difference between R and GRASS case here. The root of the problem is that the message is split into two warnings which are reported three times, so you get 6 messages when you should get just one. It could be perhaps just a (important?) message, not really a warning. In any case, it is a GRASS issue.

_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats