[GRASS-stats] wish: less verbose messages in rgrass7
Roger Bivand
Roger.Bivand at nhh.no
Thu Sep 10 03:42:31 PDT 2015
On Thu, 10 Sep 2015, Rainer M Krug wrote:
> Roger Bivand <Roger.Bivand at nhh.no> writes:
>
>> On Thu, 10 Sep 2015, Rainer M Krug wrote:
>>
>>> Markus Neteler <neteler at osgeo.org> 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 at user1>
>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>> <PERMANENT>)
>>>> WARNING: Using <elevation at user1>
>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>> <PERMANENT>)
>>>> WARNING: Using <elevation at 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 at user1>
>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>> <PERMANENT>)
>>>> WARNING: Using <elevation at user1>
>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>> <PERMANENT>)
>>>> WARNING: Using <elevation at 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 at user1>
>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>> <PERMANENT>)
>>>> WARNING: Using <elevation at user1>
>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>> <PERMANENT>)
>>>> WARNING: Using <elevation at 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 at user1>
>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>> <PERMANENT>)
>>>> WARNING: Using <elevation at user1>
>>>> WARNING: 'cellhd/elevation' was found in more mapsets (also found in
>>>> <PERMANENT>)
>>>> WARNING: Using <elevation at 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
>>>> grass-stats at lists.osgeo.org
>>>> 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: Roger.Bivand at nhh.no
More information about the grass-stats
mailing list