[GRASS-stats] wish: less verbose messages in rgrass7
Rainer M Krug
Rainer at krugs.de
Thu Sep 10 03:58:03 PDT 2015
Roger Bivand <Roger.Bivand at nhh.no> writes:
> 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?
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 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
>>>>
>>>>
>>
>>
--
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: Rainer at krugs.de
Skype: RMkrug
PGP: 0x0F52F982
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 480 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/grass-stats/attachments/20150910/48561048/attachment-0001.pgp>
More information about the grass-stats
mailing list