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

Thanks for the clarification Roger. I will be more careful about
handing out advice on functions that I have never used :).

As the author of the original example that started this mess, I would
like to contribute a new example that should generalize to those cases
where readRAST6() isn't an option. These would be cases where GRASS-R
integration is difficult (windows) or in cases where very large files
are involved.

http://casoilresource.lawr.ucdavis.edu/drupal/node/993

This example will require your own data set. Feedback is always welcome.

Cheers,
Dylan

On Thu, May 19, 2011 at 7:04 AM, Roger Bivand <Roger.Bivand at nhh.no> wrote:

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

--
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