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

[Roger Bivand]

On Tue, 24 May 2011, Dylan Beaudette wrote:

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

Hi Dylan,

Yes, this should clear up some misunderstandings! Thanks!

Best wishes,

Roger

PS. Which days are you planning to be in Landau?

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

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