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

[Dylan Beaudette]

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
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> grass-stats mailing list
> grass-stats at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-stats
>