[GRASS-stats] wish: less verbose messages in rgrass7
Rainer M Krug
Rainer at krugs.de
Thu Sep 10 02:11:15 PDT 2015
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.
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/00783457/attachment.pgp>
More information about the grass-stats
mailing list