[GRASS-stats] Re: [R-sig-Geo] readRAST6() in {spgrass6}

[Roger Bivand]

On Thu, 19 May 2011, Rainer M Krug wrote:

> Hi Roger,
>
> On Wed, May 18, 2011 at 7:56 AM, Roger Bivand <Roger.Bivand at nhh.no> wrote:
>> I do not have your location, so cannot check. It appears that your workflow
>> is highly non-standard - which you have not made clear previously. If you
>> are using spgrass6 to interface R with an existing GRASS location - which
>> seems to be the case, you should not use initGRASS(), and should not use the
>> PERMANENT mapset. The initGRASS() function is for creating one-time,
>> throwaway GRASS locations to use GRASS modules from R when no GISDBASE or
>> LOCATION is required.
>
> Could you please give some explanation, why the initGRASS() function
> should *not* be used when accessing an existing location? I use it
> extensively in my simulations to create a new mapset in a already
> existing location and I haven't experienced any problems which I would
> link to that.
> What kind of problems could occur, or why is this the non-standard
> usage of initGRASS()? I always assumed, that the idea is that
> initGRASS() actually replaces the "running R inside GRASS" approach?

The function was introduced to make it possible to use GRASS modules 
without a GRASS GISDBASE/LOCATION file tree, in throwaway mode for 
non-expert users. The advice offered was also for non-expert users: unless 
you understand fully what you are doing, choose between using R within 
GRASS for existing LOCATION file trees, and initGRASS() when you are not 
using data from "inside" GRASS. This advice holds for all users who do not 
understand the possible inconvenience of trashing their .gisrc file.

If, on the other hand, the user takes responsibility for over-riding the 
regular GRASS startup mechanisms, initGRASS() can be used, as you decribe, 
for scripting GRASS. Not every user, however, should consider this 
possibility if all of the consequences are not understood.

The main file at risk is .gisrc, but it is fully possible that the GRASS 
mapset-specific temporary files will not be cleaned up properly, and 
environment variables set by initGRASS() may interfere with GRASS in 
unexpected ways across different OS while the R session has not been 
terminated - I've not established any harmful interactions, but that 
doesn't mean that they are not present on at least some platforms. In 
principle the compute processes should not "leak", but on some OS, odd 
things happen, so being cautious rather than principled seems justified.

In the case that started this thread, the user does not seem to have had a 
clear idea of what was happening, and was copying a script found online 
intended for a different setting and an example data set. He needed to be 
pointed to a more helpful setting, that is: start GRASS (and the GRASS 
GUI) in Windows, start R in GRASS from the MSYS console, and be able to 
manipulate the current GRASS region from the GUI to tile or resample the 
data down to a size that admitted analysis.

>
> Cheers,
>
> Rainer
>
>
>>
>> --
>> Roger Bivand
>> Economic Geography Section, Department of Economics, Norwegian School of
>> Economics and Business Administration, Helleveien 30, N-5045 Bergen,
>> Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
>> e-mail: Roger.Bivand at nhh.no
>>
>> _______________________________________________
>> R-sig-Geo mailing list
>> R-sig-Geo at r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
>
>
>
>

-- 
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand at nhh.no