[GRASS-dev] Plan to build Package to use GRASS from R

[Rainer_M_Krug]

Hi

Sorry for crossposting, but I think this can be of interest for GRASS and R users.

I am planning to write a package to make the use of GRASS from R easier. The idea is to wrap the system call to execute the GRASS command into an R command of the same name.
e.g:
r.to.vect ← function(…, intern=TRUE, ignore.stderr=FALSE)
{
comm ← paste( “r.to.vect “, …, sep=”” )
print(comm)
system( comm, intern=intern, ignore.stderr=ignore.stderr )
}

My questions are:

1. Is this a good way of doing it, or is giving a named list to the function more usefull?
2. Is there a way to obtain easily all commands from GRASS and the parameters possible and required?

Any ideas and comments welcome,

Rainer

–
Rainer M. Krug, Dipl. Phys. (Germany), MSc Conservation Biology (UCT)

Plant Conservation Unit Department of Botany
University of Cape Town
Rondebosch 7701
South Africa

[Glynn_Clements1]

Rainer M Krug wrote:

Sorry for crossposting, but I think this can be of interest for GRASS and R
users.

I am planning to write a package to make the use of GRASS from R easier. The
idea is to wrap the system call to execute the GRASS command into an R
command of the same name.
e.g:
r.to.vect <- function(..., intern=TRUE, ignore.stderr=FALSE)
  {
    comm <- paste( "r.to.vect ", ..., sep="" )
    print(comm)
    system( comm, intern=intern, ignore.stderr=ignore.stderr )
  }

My questions are:

1) Is this a good way of doing it, or is giving a named list to the function
more usefull?

If R provides a way to pass individual arguments (argc/argv), use that
instead of contructing a shell command as a string. Otherwise, you are
likely to run into problems with shell metacharacters in argument
values.

2) Is there a way to obtain easily all commands from GRASS and the
parameters possible and required?

You can obtain a list of commands by enumerating the $GISBASE/bin and
$GISBASE/scripts directories. Nearly all commands support the
--interface-description switch, which outputs details of all of the
options in XML. There are several other switches which output the same
information in different formats; see the g.parser manpage for
details.

--
Glynn Clements <glynn@gclements.plus.com>

[Rainer_M_Krug]

On 27/02/2008, Glynn Clements <glynn@gclements.plus.com> wrote:

Rainer M Krug wrote:

Sorry for crossposting, but I think this can be of interest for GRASS and R
users.

I am planning to write a package to make the use of GRASS from R easier. The
idea is to wrap the system call to execute the GRASS command into an R
command of the same name.
e.g:
r.to.vect ← function(…, intern=TRUE, ignore.stderr=FALSE)
{
comm ← paste( “r.to.vect “, …, sep=”” )
print(comm)
system( comm, intern=intern, ignore.stderr=ignore.stderr )
}

My questions are:

1. Is this a good way of doing it, or is giving a named list to the function
   more usefull?

If R provides a way to pass individual arguments (argc/argv), use that
instead of contructing a shell command as a string. Otherwise, you are
likely to run into problems with shell metacharacters in argument
values.

I will lookm at that - because I already had the problems. And I would like to avoid them in the future!

2. Is there a way to obtain easily all commands from GRASS and the
   parameters possible and required?

You can obtain a list of commands by enumerating the $GISBASE/bin and
$GISBASE/scripts directories. Nearly all commands support the
–interface-description switch, which outputs details of all of the
options in XML. There are several other switches which output the same

That looks very good. I’ll look into that.

information in different formats; see the g.parser manpage for
details.

Thanks for your toips ’ I will look at them and come back if I don’t understand them.

Thanks

Rainer

–
Glynn Clements <glynn@gclements.plus.com>

–

–
Rainer M. Krug, Dipl. Phys. (Germany), MSc Conservation Biology (UCT)

Plant Conservation Unit Department of Botany
University of Cape Town
Rondebosch 7701
South Africa

[Roger_Bivand]

On Wed, 27 Feb 2008, Rainer M Krug wrote:

Hi

Sorry for crossposting, but I think this can be of interest for GRASS and R
users.

Yes, please avoid cross-posting - the discussion ends up on many different lists and threading can break down if the threading implementation in mail clients and archives doesn't like cross-posting.

The only complete thread I have found is on Nabble at:

http://www.nabble.com/Plan-to-build-Package-to-use-GRASS-from-R-tt15712877.html#a15712877

for the grass-dev list.

In summary, the problems are mostly those of appropriately quoting shell commands through system() across platforms. Those interested should follow the discussion on grass-dev.

The correct lists could be either here, or the grass-stats list; could Rainer post a summary to both (hopefully in-thread) on conclusion?

Roger

I am planning to write a package to make the use of GRASS from R easier. The
idea is to wrap the system call to execute the GRASS command into an R
command of the same name.
e.g:
r.to.vect <- function(..., intern=TRUE, ignore.stderr=FALSE)
{
   comm <- paste( "r.to.vect ", ..., sep="" )
   print(comm)
   system( comm, intern=intern, ignore.stderr=ignore.stderr )
}

My questions are:

1) Is this a good way of doing it, or is giving a named list to the function
more usefull?
2) Is there a way to obtain easily all commands from GRASS and the
parameters possible and required?

Any ideas and comments welcome,

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@nhh.no

[Rainer_M_Krug]

On 28/02/2008, Roger Bivand <Roger.Bivand@nhh.no> wrote:

On Wed, 27 Feb 2008, Rainer M Krug wrote:

Hi

Sorry for crossposting, but I think this can be of interest for GRASS and R
users.

Yes, please avoid cross-posting - the discussion ends up on many different
lists and threading can break down if the threading implementation in mail
clients and archives doesn’t like cross-posting.

OK - I’ll avoid it in the future and continue this thread on grass-dev.

The only complete thread I have found is on Nabble at:

http://www.nabble.com/Plan-to-build-Package-to-use-GRASS-from-R-tt15712877.html#a15712877

for the grass-dev list.

In summary, the problems are mostly those of appropriately quoting shell
commands through system() across platforms. Those interested should follow
the discussion on grass-dev.

The correct lists could be either here, or the grass-stats list; could

I think I will leave it at the grass-dev list, altohough it concerns grass and R - it is more a devel issue then for the grass-stats list.

Rainer post a summary to both (hopefully in-thread) on conclusion?

OK - I will do so as soon some ideas and further palns emerge.

If I have a working solution, would it be possible to include it into the spgrass6 package?

Thanks

Rainer

Roger

I am planning to write a package to make the use of GRASS from R easier. The
idea is to wrap the system call to execute the GRASS command into an R
command of the same name.
e.g:
r.to.vect ← function(…, intern=TRUE, ignore.stderr=FALSE)
{
comm ← paste( “r.to.vect “, …, sep=”” )
print(comm)
system( comm, intern=intern, ignore.stderr=ignore.stderr )
}

My questions are:

1. Is this a good way of doing it, or is giving a named list to the function
   more usefull?
2. Is there a way to obtain easily all commands from GRASS and the
   parameters possible and required?

Any ideas and comments welcome,

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@nhh.no

–

–
Rainer M. Krug, Dipl. Phys. (Germany), MSc Conservation Biology (UCT)

Plant Conservation Unit Department of Botany
University of Cape Town
Rondebosch 7701
South Africa

[Roger_Bivand]

Glynn Clements wrote:

Rainer M Krug wrote:

Sorry for crossposting, but I think this can be of interest for GRASS and
R
users.

I am planning to write a package to make the use of GRASS from R easier.
The
idea is to wrap the system call to execute the GRASS command into an R
command of the same name.
e.g:
r.to.vect <- function(..., intern=TRUE, ignore.stderr=FALSE)
  {
    comm <- paste( "r.to.vect ", ..., sep="" )
    print(comm)
    system( comm, intern=intern, ignore.stderr=ignore.stderr )
  }

My questions are:

1) Is this a good way of doing it, or is giving a named list to the
function
more usefull?

If R provides a way to pass individual arguments (argc/argv), use that
instead of contructing a shell command as a string. Otherwise, you are
likely to run into problems with shell metacharacters in argument
values.

(Replying in Nabble because Rainer's posting has been swallowed by
threading everywhere else)

This is the key sympton, seen recently in a similar interface to SAGA,
where the package author carelessly converted all "/" to "\" (it is only
on Windows), thus destroying a valid r.mapcalc-like operation.

It is made worse by differences between Unixen and Windows in handling
stdout and stderr, and by differences between CygWin and MSYS in what the
GRASS commands are called in system() - MSYS wants an *.exe.

2) Is there a way to obtain easily all commands from GRASS and the
parameters possible and required?

You can obtain a list of commands by enumerating the $GISBASE/bin and
$GISBASE/scripts directories. Nearly all commands support the
--interface-description switch, which outputs details of all of the
options in XML. There are several other switches which output the same
information in different formats; see the g.parser manpage for
details.
---
Actually, the interface problem for R is almost exactly the same as for
all the other front ends - think of R as a CLI-UI. Using XML in R to set
up commands going from R to GRASS might not be impossible, where there
would be only one command - do_GRASS(), taking the GRASS command as its
required argument, and relying on the GRASS GUI to put up a dialogue. If
there were further arguments, then they would be used in the context of
the requested command.

I haven't been following the GUI discussion, so wonder whether the
--interface-description output is cached anywhere? If not, do_GRASS()
would retrieve that first, and then try to insert given arguments, using
platform specific "glue" to move forward. Has the (excellent, by the way)
progress on GUI provided a way of passing a "bubble" (say in XML) to GRASS
commands, to avoid having to step around shell metacharacters? The same
for error handling? It feels as though g.parser will help a lot.

Roger
--
Glynn Clements <glynn@gclements.plus.com>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
View this message in context: http://www.nabble.com/Plan-to-build-Package-to-use-GRASS-from-R-tp15712877p15731306.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

[Roger_Bivand]

On Thu, 28 Feb 2008, Rainer M Krug wrote:

On 28/02/2008, Roger Bivand <Roger.Bivand@nhh.no> wrote:

On Wed, 27 Feb 2008, Rainer M Krug wrote:

Hi

Sorry for crossposting, but I think this can be of interest for GRASS

and R

users.

Yes, please avoid cross-posting - the discussion ends up on many different
lists and threading can break down if the threading implementation in mail
clients and archives doesn't like cross-posting.

OK - I'll avoid it in the future and continue this thread on grass-dev.

The only complete thread I have found is on Nabble at:

http://www.nabble.com/Plan-to-build-Package-to-use-GRASS-from-R-tt15712877.html#a15712877

for the grass-dev list.

In summary, the problems are mostly those of appropriately quoting shell
commands through system() across platforms. Those interested should follow
the discussion on grass-dev.

The correct lists could be either here, or the grass-stats list; could

I think I will leave it at the grass-dev list, altohough it concerns grass
and R - it is more a devel issue then for the grass-stats list.

Rainer post a summary to both (hopefully in-thread) on conclusion?

OK - I will do so as soon some ideas and further palns emerge.

If I have a working solution, would it be possible to include it into the
spgrass6 package?

It is actually to some extent a re-write of spgrass6, using other mechanisms to run the GRASS commands. In that context, yes, I'd be interested. See my post on grass-dev (I'm reading there digested at present).

Roger

Thanks

Rainer

Roger

I am planning to write a package to make the use of GRASS from R easier.

The

idea is to wrap the system call to execute the GRASS command into an R
command of the same name.
e.g:
r.to.vect <- function(..., intern=TRUE, ignore.stderr=FALSE)
{
   comm <- paste( "r.to.vect ", ..., sep="" )
   print(comm)
   system( comm, intern=intern, ignore.stderr=ignore.stderr )
}

My questions are:

1) Is this a good way of doing it, or is giving a named list to the

function

more usefull?
2) Is there a way to obtain easily all commands from GRASS and the
parameters possible and required?

Any ideas and comments welcome,

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@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@nhh.no

[Rainer_M_Krug]

On 28/02/2008, Roger Bivand <Roger.Bivand@nhh.no> wrote:

Glynn Clements wrote:

Rainer M Krug wrote:

Sorry for crossposting, but I think this can be of interest for GRASS and
R
users.

I am planning to write a package to make the use of GRASS from R easier.
The
idea is to wrap the system call to execute the GRASS command into an R
command of the same name.
e.g:
r.to.vect ← function(…, intern=TRUE, ignore.stderr=FALSE)
{
comm ← paste( “r.to.vect “, …, sep=”” )
print(comm)
system( comm, intern=intern, ignore.stderr=ignore.stderr )
}

My questions are:

1. Is this a good way of doing it, or is giving a named list to the
   function
   more usefull?

If R provides a way to pass individual arguments (argc/argv), use that
instead of contructing a shell command as a string. Otherwise, you are
likely to run into problems with shell metacharacters in argument
values.

(Replying in Nabble because Rainer’s posting has been swallowed by
threading everywhere else)

This is the key sympton, seen recently in a similar interface to SAGA,
where the package author carelessly converted all “/” to "" (it is only
on Windows), thus destroying a valid r.mapcalc-like operation.

It is made worse by differences between Unixen and Windows in handling
stdout and stderr, and by differences between CygWin and MSYS in what the
GRASS commands are called in system() - MSYS wants an *.exe.

R has a mechanism to detect the OS and, and that could be used to deal with “/” or "" issues as well as other differences (one thing I haven’t considered yet as) .

One way of dealing with the different OS concerning stderr and stdout would be using the command system() in R as it already adresses these issues (as far as I know) and I managed to write usable wrappers around a few of the grass commands, including r.mapcalc. But especially r.mapcalc required manual tweaking…

2. Is there a way to obtain easily all commands from GRASS and the
   parameters possible and required?

You can obtain a list of commands by enumerating the $GISBASE/bin and
$GISBASE/scripts directories. Nearly all commands support the
–interface-description switch, which outputs details of all of the
options in XML. There are several other switches which output the same
information in different formats; see the g.parser manpage for
details.

---

Actually, the interface problem for R is almost exactly the same as for
all the other front ends - think of R as a CLI-UI. Using XML in R to set
up commands going from R to GRASS might not be impossible, where there
would be only one command - do_GRASS(), taking the GRASS command as its
required argument, and relying on the GRASS GUI to put up a dialogue. If
there were further arguments, then they would be used in the context of
the requested command.

That sounds like a good approach and as a starting point - as ultimately I would like to be able to call e.g. r.in.bin() from R instead of do_GRASS(“r.in.bin”, …). I am using R a lot at the moment to write ecological simulation models, and to use the commands directly makes the programs much more readable as emacs highlights the commands. I will look into xml parsers under R to geth the information out of the grass command.

I haven’t been following the GUI discussion, so wonder whether the
–interface-description output is cached anywhere? If not, do_GRASS()
would retrieve that first, and then try to insert given arguments, using
platform specific “glue” to move forward. Has the (excellent, by the way)
progress on GUI provided a way of passing a “bubble” (say in XML) to GRASS
commands, to avoid having to step around shell metacharacters? The same
for error handling? It feels as though g.parser will help a lot.

If the grass commands are created automatically and included into a package (in addition to the flexible do_GRASS()), this would not be that relevant, as the creation of the code only happens once (either at coding time of the package or at compilation time - that would make the system much more flexible as only GRASS commands / scripts installed be available).

Rainer

Roger

–
Glynn Clements <glynn@gclements.plus.com>

---

grass-dev mailing list

grass-dev@lists.osgeo.org

http://lists.osgeo.org/mailman/listinfo/grass-dev

–
View this message in context: http://www.nabble.com/Plan-to-build-Package-to-use-GRASS-from-R-tp15712877p15731306.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

---

grass-dev mailing list

grass-dev@lists.osgeo.org

http://lists.osgeo.org/mailman/listinfo/grass-dev

–

–
Rainer M. Krug, Dipl. Phys. (Germany), MSc Conservation Biology (UCT)

Plant Conservation Unit Department of Botany
University of Cape Town
Rondebosch 7701
South Africa

[Roger_Bivand]

On Thu, 28 Feb 2008, Rainer M Krug wrote:

On 28/02/2008, Roger Bivand <Roger.Bivand@nhh.no> wrote:

Glynn Clements wrote:

Rainer M Krug wrote:

Sorry for crossposting, but I think this can be of interest for GRASS

and

R
users.

I am planning to write a package to make the use of GRASS from R

easier.

The
idea is to wrap the system call to execute the GRASS command into an R
command of the same name.
e.g:
r.to.vect <- function(..., intern=TRUE, ignore.stderr=FALSE)
  {
    comm <- paste( "r.to.vect ", ..., sep="" )
    print(comm)
    system( comm, intern=intern, ignore.stderr=ignore.stderr )
  }

My questions are:

1) Is this a good way of doing it, or is giving a named list to the
function
more usefull?

If R provides a way to pass individual arguments (argc/argv), use that
instead of contructing a shell command as a string. Otherwise, you are
likely to run into problems with shell metacharacters in argument
values.

(Replying in Nabble because Rainer's posting has been swallowed by
threading everywhere else)

This is the key sympton, seen recently in a similar interface to SAGA,
where the package author carelessly converted all "/" to "\" (it is only
on Windows), thus destroying a valid r.mapcalc-like operation.

It is made worse by differences between Unixen and Windows in handling
stdout and stderr, and by differences between CygWin and MSYS in what

the

GRASS commands are called in system() - MSYS wants an *.exe.

R has a mechanism to detect the OS and, and that could be used to deal with
"/" or "\" issues as well as other differences (one thing I haven't
considered yet as) .
One way of dealing with the different OS concerning stderr and stdout would
be using the command system() in R as it already adresses these issues (as
far as I know) and I managed to write usable wrappers around a few of the
grass commands, including r.mapcalc. But especially r.mapcalc required
manual tweaking...

It is precisely manual tweaking that gets broken ...

2) Is there a way to obtain easily all commands from GRASS and the
parameters possible and required?

You can obtain a list of commands by enumerating the $GISBASE/bin and
$GISBASE/scripts directories. Nearly all commands support the
--interface-description switch, which outputs details of all of the
options in XML. There are several other switches which output the same
information in different formats; see the g.parser manpage for
details.

---
Actually, the interface problem for R is almost exactly the same as for
all the other front ends - think of R as a CLI-UI. Using XML in R to set
up commands going from R to GRASS might not be impossible, where there
would be only one command - do_GRASS(), taking the GRASS command as its
required argument, and relying on the GRASS GUI to put up a dialogue. If
there were further arguments, then they would be used in the context of
the requested command.

That sounds like a good approach and as a starting point - as ultimately I
would like to be able to call e.g. r.in.bin() from R instead of do_GRASS("
r.in.bin", ...). I am using R a lot at the moment to write ecological
simulation models, and to use the commands directly makes the programs much
more readable as emacs highlights the commands. I will look into xml parsers
under R to geth the information out of the grass command.

The workhorse has to be a do_GRASS() talking to GRASS in a standardised way (mirroring g.parser?). Whether you then generate aliases for it taking the names of the first argument is a detail, but not a trivial one. You will certainly need a NAMESPACE in R, and do_GRASS() will be several orders of magnitude easier to debug. The GRASS command names are not guaranteed to be unique seen from the R side - load a contributed package into the R workspace with its own g.list(), say, and which one will you get?

Roger

I haven't been following the GUI discussion, so wonder whether the
--interface-description output is cached anywhere? If not, do_GRASS()
would retrieve that first, and then try to insert given arguments, using
platform specific "glue" to move forward. Has the (excellent, by the

way)

progress on GUI provided a way of passing a "bubble" (say in XML) to

GRASS

commands, to avoid having to step around shell metacharacters? The same
for error handling? It feels as though g.parser will help a lot.

If the grass commands are created automatically and included into a package
(in addition to the flexible do_GRASS()), this would not be that relevant,
as the creation of the code only happens once (either at coding time of the
package or at compilation time - that would make the system much more
flexible as only GRASS commands / scripts installed be available).

Rainer

Roger

--
Glynn Clements <glynn@gclements.plus.com>

_______________________________________________
grass-dev mailing list

grass-dev@lists.osgeo.org

http://lists.osgeo.org/mailman/listinfo/grass-dev

--
View this message in context:
http://www.nabble.com/Plan-to-build-Package-to-use-GRASS-from-R-tp15712877p15731306.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

_______________________________________________
grass-dev mailing list

grass-dev@lists.osgeo.org

http://lists.osgeo.org/mailman/listinfo/grass-dev

--
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@nhh.no

[Rainer_M_Krug]

On 28/02/2008, Roger Bivand <Roger.Bivand@nhh.no> wrote:

On Thu, 28 Feb 2008, Rainer M Krug wrote:

On 28/02/2008, Roger Bivand <Roger.Bivand@nhh.no> wrote:

Glynn Clements wrote:

Rainer M Krug wrote:

Sorry for crossposting, but I think this can be of interest for GRASS
and
R
users.

I am planning to write a package to make the use of GRASS from R
easier.
The
idea is to wrap the system call to execute the GRASS command into an R
command of the same name.
e.g:
r.to.vect ← function(…, intern=TRUE, ignore.stderr=FALSE)
{
comm ← paste( “r.to.vect “, …, sep=”” )
print(comm)
system( comm, intern=intern, ignore.stderr=ignore.stderr )
}

My questions are:

1. Is this a good way of doing it, or is giving a named list to the
   function
   more usefull?

If R provides a way to pass individual arguments (argc/argv), use that
instead of contructing a shell command as a string. Otherwise, you are
likely to run into problems with shell metacharacters in argument
values.

(Replying in Nabble because Rainer’s posting has been swallowed by
threading everywhere else)

This is the key sympton, seen recently in a similar interface to SAGA,
where the package author carelessly converted all “/” to "" (it is only
on Windows), thus destroying a valid r.mapcalc-like operation.

It is made worse by differences between Unixen and Windows in handling
stdout and stderr, and by differences between CygWin and MSYS in what
the
GRASS commands are called in system() - MSYS wants an *.exe.

R has a mechanism to detect the OS and, and that could be used to deal with
“/” or "" issues as well as other differences (one thing I haven’t
considered yet as) .
One way of dealing with the different OS concerning stderr and stdout would
be using the command system() in R as it already adresses these issues (as
far as I know) and I managed to write usable wrappers around a few of the
grass commands, including r.mapcalc. But especially r.mapcalc required
manual tweaking…

It is precisely manual tweaking that gets broken …

That’s why I would like to avoid it…

2. Is there a way to obtain easily all commands from GRASS and the
   parameters possible and required?

You can obtain a list of commands by enumerating the $GISBASE/bin and
$GISBASE/scripts directories. Nearly all commands support the
–interface-description switch, which outputs details of all of the
options in XML. There are several other switches which output the same
information in different formats; see the g.parser manpage for
details.

---

Actually, the interface problem for R is almost exactly the same as for
all the other front ends - think of R as a CLI-UI. Using XML in R to set
up commands going from R to GRASS might not be impossible, where there
would be only one command - do_GRASS(), taking the GRASS command as its
required argument, and relying on the GRASS GUI to put up a dialogue. If
there were further arguments, then they would be used in the context of
the requested command.

That sounds like a good approach and as a starting point - as ultimately I
would like to be able to call e.g. r.in.bin() from R instead of do_GRASS("
r.in.bin", …). I am using R a lot at the moment to write ecological
simulation models, and to use the commands directly makes the programs much
more readable as emacs highlights the commands. I will look into xml parsers
under R to geth the information out of the grass command.

The workhorse has to be a do_GRASS() talking to GRASS in a standardised
way (mirroring g.parser?). Whether you then generate aliases for it taking
the names of the first argument is a detail, but not a trivial one. You

will certainly need a NAMESPACE in R, and do_GRASS() will be several
orders of magnitude easier to debug.

I agree completely. But for readability, I would still like to have these wrappsers. But One could leave them for a later stage and to get do_GRASS() working.

The GRASS command names are not

guaranteed to be unique seen from the R side - load a contributed package
into the R workspace with its own g.list(), say, and which one will you
get?

Isn’t that a general problem with using packages? There are several packages which overwrite other functions in other packages and they give a warning message when loading. But it would be nice to avoid these conflicts - one could introduce these wrappers as g.list.GRASS().
As an emacs user, I would actually prefer using do.GRASS() instead of do_GRASS() - but that is a minor point. As far as I know, there are no conventions in R concerning this?

Rainer

Roger

I haven’t been following the GUI discussion, so wonder whether the
–interface-description output is cached anywhere? If not, do_GRASS()
would retrieve that first, and then try to insert given arguments, using
platform specific “glue” to move forward. Has the (excellent, by the
way)
progress on GUI provided a way of passing a “bubble” (say in XML) to
GRASS
commands, to avoid having to step around shell metacharacters? The same
for error handling? It feels as though g.parser will help a lot.

If the grass commands are created automatically and included into a package
(in addition to the flexible do_GRASS()), this would not be that relevant,
as the creation of the code only happens once (either at coding time of the
package or at compilation time - that would make the system much more
flexible as only GRASS commands / scripts installed be available).

Rainer

Roger

–
Glynn Clements <glynn@gclements.plus.com>

---

grass-dev mailing list

grass-dev@lists.osgeo.org

http://lists.osgeo.org/mailman/listinfo/grass-dev

–
View this message in context:
http://www.nabble.com/Plan-to-build-Package-to-use-GRASS-from-R-tp15712877p15731306.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

---

grass-dev mailing list

grass-dev@lists.osgeo.org

http://lists.osgeo.org/mailman/listinfo/grass-dev

–

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@nhh.no

–

–
Rainer M. Krug, Dipl. Phys. (Germany), MSc Conservation Biology (UCT)

Plant Conservation Unit Department of Botany
University of Cape Town
Rondebosch 7701
South Africa

[Roger_Bivand]

On Thu, 28 Feb 2008, Rainer M Krug wrote:

On 28/02/2008, Roger Bivand <Roger.Bivand@nhh.no> wrote:

On Thu, 28 Feb 2008, Rainer M Krug wrote:

On 28/02/2008, Roger Bivand <Roger.Bivand@nhh.no> wrote:

Glynn Clements wrote:

Rainer M Krug wrote:

Sorry for crossposting, but I think this can be of interest for GRASS

and

R
users.

I am planning to write a package to make the use of GRASS from R

easier.

The
idea is to wrap the system call to execute the GRASS command into an

R

command of the same name.
e.g:
r.to.vect <- function(..., intern=TRUE, ignore.stderr=FALSE)
  {
    comm <- paste( "r.to.vect ", ..., sep="" )
    print(comm)
    system( comm, intern=intern, ignore.stderr=ignore.stderr )
  }

My questions are:

1) Is this a good way of doing it, or is giving a named list to the
function
more usefull?

If R provides a way to pass individual arguments (argc/argv), use that
instead of contructing a shell command as a string. Otherwise, you are
likely to run into problems with shell metacharacters in argument
values.

(Replying in Nabble because Rainer's posting has been swallowed by
threading everywhere else)

This is the key sympton, seen recently in a similar interface to SAGA,
where the package author carelessly converted all "/" to "\" (it is

only

on Windows), thus destroying a valid r.mapcalc-like operation.

It is made worse by differences between Unixen and Windows in handling
stdout and stderr, and by differences between CygWin and MSYS in what

the

GRASS commands are called in system() - MSYS wants an *.exe.

R has a mechanism to detect the OS and, and that could be used to deal

with

"/" or "\" issues as well as other differences (one thing I haven't
considered yet as) .
One way of dealing with the different OS concerning stderr and stdout

would

be using the command system() in R as it already adresses these issues

(as

far as I know) and I managed to write usable wrappers around a few of

the

grass commands, including r.mapcalc. But especially r.mapcalc required
manual tweaking...

It is precisely manual tweaking that gets broken ...

That's why I would like to avoid it...

2) Is there a way to obtain easily all commands from GRASS and the
parameters possible and required?

You can obtain a list of commands by enumerating the $GISBASE/bin and
$GISBASE/scripts directories. Nearly all commands support the
--interface-description switch, which outputs details of all of the
options in XML. There are several other switches which output the same
information in different formats; see the g.parser manpage for
details.

---
Actually, the interface problem for R is almost exactly the same as

for

all the other front ends - think of R as a CLI-UI. Using XML in R to

set

up commands going from R to GRASS might not be impossible, where there
would be only one command - do_GRASS(), taking the GRASS command as

its

required argument, and relying on the GRASS GUI to put up a dialogue.

If

there were further arguments, then they would be used in the context

of

the requested command.

That sounds like a good approach and as a starting point - as ultimately

I

would like to be able to call e.g. r.in.bin() from R instead of

do_GRASS("

r.in.bin", ...). I am using R a lot at the moment to write ecological
simulation models, and to use the commands directly makes the programs

much

more readable as emacs highlights the commands. I will look into xml

parsers

under R to geth the information out of the grass command.

The workhorse has to be a do_GRASS() talking to GRASS in a standardised
way (mirroring g.parser?). Whether you then generate aliases for it taking
the names of the first argument is a detail, but not a trivial one. You

will certainly need a NAMESPACE in R, and do_GRASS() will be several

orders of magnitude easier to debug.

I agree completely. But for readability, I would still like to have these
wrappsers. But One could leave them for a later stage and to get do_GRASS()
working.

The GRASS command names are not

guaranteed to be unique seen from the R side - load a contributed package

into the R workspace with its own g.list(), say, and which one will you
get?

Isn't that a general problem with using packages? There are several packages
which overwrite other functions in other packages and they give a warning
message when loading.

But the others *are* still available through namespaces, if the contributed package author used a NAMESPACE.

But it would be nice to avoid these conflicts - one
could introduce these wrappers as g.list.GRASS().
As an emacs user, I would actually prefer using do.GRASS() instead of
do_GRASS() - but that is a minor point. As far as I know, there are no
conventions in R concerning this?

Please note that generic methods dispatch on the .* of names for S3 (old-style) classes. I don't think that "GRASS" is used as an S3 class name, but if it was, you'd get badly hurt by that. You need to look at the class/method system too.

For example, summary.lm() is a different method from summary.default(), and both are used as summary() dispatching on the class of the first argument. I used to use "." in function names but now largely avoid it for this reason. do.GRASS would be a "do" method for an object of S3 class "GRASS". Visual editor concerns are minor by comparison. This will also (as you can see) impact the use of regular GRASS command names as R functions.

Roger

Rainer

Roger

I haven't been following the GUI discussion, so wonder whether the
--interface-description output is cached anywhere? If not, do_GRASS()
would retrieve that first, and then try to insert given arguments,

using

platform specific "glue" to move forward. Has the (excellent, by the

way)

progress on GUI provided a way of passing a "bubble" (say in XML) to

GRASS

commands, to avoid having to step around shell metacharacters? The

same

for error handling? It feels as though g.parser will help a lot.

If the grass commands are created automatically and included into a

package

(in addition to the flexible do_GRASS()), this would not be that

relevant,

as the creation of the code only happens once (either at coding time of

the

package or at compilation time - that would make the system much more
flexible as only GRASS commands / scripts installed be available).

Rainer

Roger

--
Glynn Clements <glynn@gclements.plus.com>

_______________________________________________
grass-dev mailing list

grass-dev@lists.osgeo.org

http://lists.osgeo.org/mailman/listinfo/grass-dev

--
View this message in context:

http://www.nabble.com/Plan-to-build-Package-to-use-GRASS-from-R-tp15712877p15731306.html

Sent from the Grass - Dev mailing list archive at Nabble.com.

_______________________________________________
grass-dev mailing list

grass-dev@lists.osgeo.org

http://lists.osgeo.org/mailman/listinfo/grass-dev

--

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@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@nhh.no

[Rainer_M_Krug]

On 28/02/2008, Roger Bivand <Roger.Bivand@nhh.no> wrote:

On Thu, 28 Feb 2008, Rainer M Krug wrote:

On 28/02/2008, Roger Bivand <Roger.Bivand@nhh.no> wrote:

On Thu, 28 Feb 2008, Rainer M Krug wrote:

On 28/02/2008, Roger Bivand <Roger.Bivand@nhh.no> wrote:

Glynn Clements wrote:

Rainer M Krug wrote:

Sorry for crossposting, but I think this can be of interest for GRASS
and
R
users.

I am planning to write a package to make the use of GRASS from R
easier.
The
idea is to wrap the system call to execute the GRASS command into an
R
command of the same name.
e.g:
r.to.vect ← function(…, intern=TRUE, ignore.stderr=FALSE)
{
comm ← paste( “r.to.vect “, …, sep=”” )
print(comm)
system( comm, intern=intern, ignore.stderr=ignore.stderr )
}

My questions are:

1. Is this a good way of doing it, or is giving a named list to the
   function
   more usefull?

If R provides a way to pass individual arguments (argc/argv), use that
instead of contructing a shell command as a string. Otherwise, you are
likely to run into problems with shell metacharacters in argument
values.

(Replying in Nabble because Rainer’s posting has been swallowed by
threading everywhere else)

This is the key sympton, seen recently in a similar interface to SAGA,
where the package author carelessly converted all “/” to "" (it is
only
on Windows), thus destroying a valid r.mapcalc-like operation.

It is made worse by differences between Unixen and Windows in handling
stdout and stderr, and by differences between CygWin and MSYS in what
the
GRASS commands are called in system() - MSYS wants an *.exe.

R has a mechanism to detect the OS and, and that could be used to deal
with
“/” or "" issues as well as other differences (one thing I haven’t
considered yet as) .
One way of dealing with the different OS concerning stderr and stdout
would
be using the command system() in R as it already adresses these issues
(as
far as I know) and I managed to write usable wrappers around a few of
the
grass commands, including r.mapcalc. But especially r.mapcalc required
manual tweaking…

It is precisely manual tweaking that gets broken …

That’s why I would like to avoid it…

2. Is there a way to obtain easily all commands from GRASS and the
   parameters possible and required?

You can obtain a list of commands by enumerating the $GISBASE/bin and
$GISBASE/scripts directories. Nearly all commands support the
–interface-description switch, which outputs details of all of the
options in XML. There are several other switches which output the same
information in different formats; see the g.parser manpage for
details.

---

Actually, the interface problem for R is almost exactly the same as
for
all the other front ends - think of R as a CLI-UI. Using XML in R to
set
up commands going from R to GRASS might not be impossible, where there
would be only one command - do_GRASS(), taking the GRASS command as
its
required argument, and relying on the GRASS GUI to put up a dialogue.
If
there were further arguments, then they would be used in the context
of
the requested command.

That sounds like a good approach and as a starting point - as ultimately
I
would like to be able to call e.g. r.in.bin() from R instead of
do_GRASS("
r.in.bin", …). I am using R a lot at the moment to write ecological
simulation models, and to use the commands directly makes the programs
much
more readable as emacs highlights the commands. I will look into xml
parsers
under R to geth the information out of the grass command.

The workhorse has to be a do_GRASS() talking to GRASS in a standardised
way (mirroring g.parser?). Whether you then generate aliases for it taking
the names of the first argument is a detail, but not a trivial one. You

will certainly need a NAMESPACE in R, and do_GRASS() will be several

orders of magnitude easier to debug.

I agree completely. But for readability, I would still like to have these
wrappsers. But One could leave them for a later stage and to get do_GRASS()
working.

The GRASS command names are not

guaranteed to be unique seen from the R side - load a contributed package

into the R workspace with its own g.list(), say, and which one will you
get?

Isn’t that a general problem with using packages? There are several packages
which overwrite other functions in other packages and they give a warning
message when loading.

But the others are still available through namespaces, if the
contributed package author used a NAMESPACE.

Yes - that’s true. I haven’t used namespaces so far, but I think I should.

But it would be nice to avoid these conflicts - one
could introduce these wrappers as g.list.GRASS().
As an emacs user, I would actually prefer using do.GRASS() instead of
do_GRASS() - but that is a minor point. As far as I know, there are no
conventions in R concerning this?

Please note that generic methods dispatch on the .* of names for S3
(old-style) classes. I don’t think that “GRASS” is used as an S3 class
name, but if it was, you’d get badly hurt by that. You need to look at the
class/method system too.

For example, summary.lm() is a different method from summary.default(),
and both are used as summary() dispatching on the class of the first
argument. I used to use “.” in function names but now largely avoid it for
this reason. do.GRASS would be a “do” method for an object of S3 class
“GRASS”. Visual editor concerns are minor by comparison. This will also
(as you can see) impact the use of regular GRASS command names as R
functions.

I think you convinced me. But the _ is so unhandy under EMACS… But I will stick with it as it makes sense.
I looked into the XML package for R, and it looks promising for parsing the return value from --interface-description. I’ll follow this line of ideas and let you know of any progress.
But if the xml needs to be evaluated each time do_GRASS() is called, it will slow it down considerably. I think the use of a cached version of the interface description (in an Rdata file probably or in an additional XML structure?) will be the most efficient way of doing it. It could be updated at the first call of a GRASS command with do_GRASS() or manually whenever GRASS is updated.

Rainer

Roger

Rainer

Roger

I haven’t been following the GUI discussion, so wonder whether the
–interface-description output is cached anywhere? If not, do_GRASS()
would retrieve that first, and then try to insert given arguments,
using
platform specific “glue” to move forward. Has the (excellent, by the
way)
progress on GUI provided a way of passing a “bubble” (say in XML) to
GRASS
commands, to avoid having to step around shell metacharacters? The
same
for error handling? It feels as though g.parser will help a lot.

If the grass commands are created automatically and included into a
package
(in addition to the flexible do_GRASS()), this would not be that
relevant,
as the creation of the code only happens once (either at coding time of
the
package or at compilation time - that would make the system much more
flexible as only GRASS commands / scripts installed be available).

Rainer

Roger

–
Glynn Clements <glynn@gclements.plus.com>

---

grass-dev mailing list

grass-dev@lists.osgeo.org

http://lists.osgeo.org/mailman/listinfo/grass-dev

–
View this message in context:

http://www.nabble.com/Plan-to-build-Package-to-use-GRASS-from-R-tp15712877p15731306.html

Sent from the Grass - Dev mailing list archive at Nabble.com.

---

grass-dev mailing list

grass-dev@lists.osgeo.org

http://lists.osgeo.org/mailman/listinfo/grass-dev

–

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@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@nhh.no

–

–
Rainer M. Krug, Dipl. Phys. (Germany), MSc Conservation Biology (UCT)

Plant Conservation Unit Department of Botany
University of Cape Town
Rondebosch 7701
South Africa

[Roger_Bivand]

On Thu, 28 Feb 2008, Roger Bivand wrote:

On Thu, 28 Feb 2008, Rainer M Krug wrote:

On 28/02/2008, Roger Bivand <Roger.Bivand@nhh.no> wrote:
> > On Thu, 28 Feb 2008, Rainer M Krug wrote:
> > > > On 28/02/2008, Roger Bivand <Roger.Bivand@nhh.no> wrote:
> > > > > > > > > > > > > > > Glynn Clements wrote:
> > > > > > > > > > > > Rainer M Krug wrote:
> > > > > > > > > Sorry for crossposting, but I think this can be of interest for > > > > > GRASS
> > > and
> > > > > R
> > > > > users.
> > > > > > > > > > I am planning to write a package to make the use of GRASS from R
> > > easier.
> > > > > The
> > > > > idea is to wrap the system call to execute the GRASS command > > > > > into an
> R
> > > > > command of the same name.
> > > > > e.g:
> > > > > r.to.vect <- function(..., intern=TRUE, ignore.stderr=FALSE)
> > > > > {
> > > > > comm <- paste( "r.to.vect ", ..., sep="" )
> > > > > print(comm)
> > > > > system( comm, intern=intern, ignore.stderr=ignore.stderr )
> > > > > }
> > > > > > > > > > My questions are:
> > > > > > > > > > 1) Is this a good way of doing it, or is giving a named list to > > > > > the
> > > > > function
> > > > > more usefull?
> > > > > > > > If R provides a way to pass individual arguments (argc/argv), use > > > > that
> > > > instead of contructing a shell command as a string. Otherwise, you > > > > are
> > > > likely to run into problems with shell metacharacters in argument
> > > > values.
> > > > > > > > > > > (Replying in Nabble because Rainer's posting has been swallowed by
> > > > threading everywhere else)
> > > > > > > > This is the key sympton, seen recently in a similar interface > > > > to SAGA, where the package author carelessly converted all "/" > > > > to "\" (it is
> only
> > > > on Windows), thus destroying a valid r.mapcalc-like operation.
> > > > > > > > It is made worse by differences between Unixen and Windows in > > > > handling
> > > > stdout and stderr, and by differences between CygWin and MSYS in > > > > what
> > > the
> > > > GRASS commands are called in system() - MSYS wants an *.exe.
> > > > > > R has a mechanism to detect the OS and, and that could be used to deal
> with
> > "/" or "\" issues as well as other differences (one thing I haven't
> > considered yet as) .
> > One way of dealing with the different OS concerning stderr and stdout
> would
> > be using the command system() in R as it already adresses these issues
> (as
> > far as I know) and I managed to write usable wrappers around a few of
> the
> > grass commands, including r.mapcalc. But especially r.mapcalc required
> > manual tweaking...
> > > It is precisely manual tweaking that gets broken ...

That's why I would like to avoid it...

> > > > > > > > > 2) Is there a way to obtain easily all commands from GRASS and > > > > > the
> > > > > parameters possible and required?
> > > > > > > > You can obtain a list of commands by enumerating the > > > > $GISBASE/bin and $GISBASE/scripts directories. Nearly all > > > > commands support the --interface-description switch, which > > > > outputs details of all of the options in XML. There are > > > > several other switches which output the same information in > > > > different formats; see the g.parser manpage for details.

Initial trials indicate that the XML package can parse the grass interface DTD and the --interface-description output, but I haven't put them together yet. If you know XML, this appears to be a fruitful way to use tried mechanisms used in ongoing development for generating templates within R to build command strings for system(). Some grass modules don't support --interface-description, but I think not many.

Roger

> > > > > > > ---
> > > > Actually, the interface problem for R is almost exactly the same > > > > as
> for
> > > > all the other front ends - think of R as a CLI-UI. Using XML in R > > > > to
> set
> > > > up commands going from R to GRASS might not be impossible, where > > > > there
> > > > would be only one command - do_GRASS(), taking the GRASS command > > > > as
> its
> > > > required argument, and relying on the GRASS GUI to put up a > > > > dialogue.
> If
> > > > there were further arguments, then they would be used in the > > > > context
> of
> > > > the requested command.
> > > > > > That sounds like a good approach and as a starting point - as > > ultimately
> I
> > would like to be able to call e.g. r.in.bin() from R instead of
> do_GRASS("
> > r.in.bin", ...). I am using R a lot at the moment to write ecological
> > simulation models, and to use the commands directly makes the programs
> much
> > more readable as emacs highlights the commands. I will look into xml
> parsers
> > under R to geth the information out of the grass command.
> > > The workhorse has to be a do_GRASS() talking to GRASS in a standardised
> way (mirroring g.parser?). Whether you then generate aliases for it > taking
> the names of the first argument is a detail, but not a trivial one. You

will certainly need a NAMESPACE in R, and do_GRASS() will be several
> orders of magnitude easier to debug.

I agree completely. But for readability, I would still like to have these
wrappsers. But One could leave them for a later stage and to get
do_GRASS()
working.

The GRASS command names are not

guaranteed to be unique seen from the R side - load a contributed package
> into the R workspace with its own g.list(), say, and which one will you
> get?

Isn't that a general problem with using packages? There are several
packages
which overwrite other functions in other packages and they give a warning
message when loading.

But the others *are* still available through namespaces, if the contributed package author used a NAMESPACE.

But it would be nice to avoid these conflicts - one
could introduce these wrappers as g.list.GRASS().
As an emacs user, I would actually prefer using do.GRASS() instead of
do_GRASS() - but that is a minor point. As far as I know, there are no
conventions in R concerning this?

Please note that generic methods dispatch on the .* of names for S3 (old-style) classes. I don't think that "GRASS" is used as an S3 class name, but if it was, you'd get badly hurt by that. You need to look at the class/method system too.

For example, summary.lm() is a different method from summary.default(), and both are used as summary() dispatching on the class of the first argument. I used to use "." in function names but now largely avoid it for this reason. do.GRASS would be a "do" method for an object of S3 class "GRASS". Visual editor concerns are minor by comparison. This will also (as you can see) impact the use of regular GRASS command names as R functions.

Roger

Rainer

Roger
> > > > > > > > > > > > > > I haven't been following the GUI discussion, so wonder whether the
> > > > --interface-description output is cached anywhere? If not, > > > > do_GRASS()
> > > > would retrieve that first, and then try to insert given arguments,
> using
> > > > platform specific "glue" to move forward. Has the (excellent, by > > > > the
> > > way)
> > > > progress on GUI provided a way of passing a "bubble" (say in XML) > > > > to
> > > GRASS
> > > > commands, to avoid having to step around shell metacharacters? The
> same
> > > > for error handling? It feels as though g.parser will help a lot.
> > > > > > If the grass commands are created automatically and included into a
> package
> > (in addition to the flexible do_GRASS()), this would not be that
> relevant,
> > as the creation of the code only happens once (either at coding time > > of
> the
> > package or at compilation time - that would make the system much more
> > flexible as only GRASS commands / scripts installed be available).
> > > > Rainer
> > > > > > > > > Roger
> > > > > > > --
> > > > Glynn Clements <glynn@gclements.plus.com>
> > > > > > > _______________________________________________
> > > > grass-dev mailing list
> > > > > > > grass-dev@lists.osgeo.org
> > > > > > > http://lists.osgeo.org/mailman/listinfo/grass-dev
> > > > > > > > > > > > > > --
> > > View this message in context:
> > > > http://www.nabble.com/Plan-to-build-Package-to-use-GRASS-from-R-tp15712877p15731306.html
> > > Sent from the Grass - Dev mailing list archive at Nabble.com.
> > > > > > _______________________________________________
> > > grass-dev mailing list
> > > > > > grass-dev@lists.osgeo.org
> > > > > > http://lists.osgeo.org/mailman/listinfo/grass-dev
> > > > > > > > > > > > > --
> > 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@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@nhh.no

[Hamish]

Roger:

Some grass modules don't support --interface-description, but I think
not many.

r.mapcalc being the primary concern. Most of the remaining rest are
interactive things which wouldn't be useful from R. I don't think it's
a huge effort to do something special for r.mapcalc, chances are you
might want to do something special with it anyway.

You can use the r.mapcalculator script as a frontend if you need one
with a working --interface-description.

Hamish

      ____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

[Roger_Bivand]

On Thu, 28 Feb 2008, Hamish wrote:

Roger:

Some grass modules don't support --interface-description, but I think
not many.

r.mapcalc being the primary concern. Most of the remaining rest are
interactive things which wouldn't be useful from R. I don't think it's
a huge effort to do something special for r.mapcalc, chances are you
might want to do something special with it anyway.

You can use the r.mapcalculator script as a frontend if you need one
with a working --interface-description.

Right, had found that, thanks!

I'd argue that r.mapcalculator will be good enough. If users need all the strength of r.mapcalc, they can say system("bash") and do it from the shell, returning to R by closing the shell. The history file for the under-shell will not, however, be recorded (at least not in the same place).

Roger

Hamish

     ____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
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@nhh.no

[Rainer_M_Krug]

On 28/02/2008, Roger Bivand <Roger.Bivand@nhh.no> wrote:

On Thu, 28 Feb 2008, Hamish wrote:

Roger:

Some grass modules don’t support --interface-description, but I think
not many.

r.mapcalc being the primary concern. Most of the remaining rest are
interactive things which wouldn’t be useful from R. I don’t think it’s
a huge effort to do something special for r.mapcalc, chances are you
might want to do something special with it anyway.

You can use the r.mapcalculator script as a frontend if you need one
with a working --interface-description.

Right, had found that, thanks!

I’d argue that r.mapcalculator will be good enough. If users need all the
strength of r.mapcalc, they can say system(“bash”) and do it from the
shell, returning to R by closing the shell. The history file for the
under-shell will not, however, be recorded (at least not in the same
place).

I actually managed to get r.mapcalc working quite nicely without any hassles so far. I agree that this could be excluded from the do_GRASS() or at least get internally a special treatment (r.mapcalc was actually one reason why I used GRASS from R as it was much easier then using internal R mechanisms for that.)

Rainer

Roger

Hamish

---

Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

---

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

–
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@nhh.no

–

–
Rainer M. Krug, Dipl. Phys. (Germany), MSc Conservation Biology (UCT)

Plant Conservation Unit Department of Botany
University of Cape Town
Rondebosch 7701
South Africa

[Rainer_M_Krug]

I finally started working on the implementation of grass commands from
R and most of the translation from the the output from
--interface-description is working. I just have one question at the
moment: some flags require "--" and others "-" and I could not fiind
any indication in the
--interface-description output which one uses which.

Any ideas where I can get that info from?

Thanks

Rainer

On Thu, Feb 28, 2008 at 3:11 PM, Rainer M Krug <r.m.krug@gmail.com> wrote:

On 28/02/2008, Roger Bivand <Roger.Bivand@nhh.no> wrote:

On Thu, 28 Feb 2008, Rainer M Krug wrote:

> On 28/02/2008, Roger Bivand <Roger.Bivand@nhh.no> wrote:
>>
>> Rainer:
>>
>> These CRAN packages seem to use XML, somewhere there maybe there will
>> be
>> some useful examples of code for parsing the DTD and using it on the
>> XML
>> description:
>>
>>> names(nn$label)
>> [1] "XML" "Ryacas" "StatDataML" "caMassClass" "grImport"
>> [6] "odfWeave" "pmml" "rpubchem" "tm"
>>
>> The equivalent for Bioconductor, where XML is used for metadata for
>> gene
>> arrays, there are more packages:
>>
>>> names(nn$label)
>> [1] "XML" "AnnBuilder" "ChromoViz" "GSEABase"
>> [5] "GeneTraffic" "KEGGSOAP" "RSNPper" "Resourcerer"
>> [9] "Rintact" "SAGElyzer" "SBMLR" "ScISI"
>> [13] "affycoretools" "biocViews" "biomaRt" "flowUtils"
>> [17] "simulatorAPMS" "splicegear" "widgetInvoke"
>>
>> Hope this helps,
>
>
> Yes - definitely. I looked at the XML package and it seems to be
> usefull. I
> will look at how these packages use XML.

I think that StatDataML is closest, and probably simplest.

Thanks - I'll look at it -- the easier the better.

Roger

>
> Rainer
>
> Roger
>>
>>
>> --
>>
>> 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@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@nhh.no

--

--
Rainer M. Krug, Dipl. Phys. (Germany), MSc Conservation Biology (UCT)

Plant Conservation Unit Department of Botany
University of Cape Town
Rondebosch 7701
South Africa

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)

Plant Conservation Unit
Department of Botany
University of Cape Town
Rondebosch 7701
South Africa

[martinl]

Hi,

2008/7/2 Rainer M Krug <r.m.krug@gmail.com>:

I finally started working on the implementation of grass commands from
R and most of the translation from the the output from
--interface-description is working. I just have one question at the
moment: some flags require "--" and others "-" and I could not fiind
any indication in the
--interface-description output which one uses which.

I guess, basically one-letter flags use '-' othewise '--', e.g.

       <flag name="g">
                <label>
                        Shell script style, currently only for report
                </label>
                <description>
                        Format: layer type count min max
                </description>
        </flag>
        <flag name="overwrite">
                <description>
                        Allow output files to overwrite existing files
                </description>
        </flag>

-> '-g' / '--overwrite' (or '--o')

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

[Rainer_M_Krug]

On Wed, Jul 2, 2008 at 4:22 PM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

2008/7/2 Rainer M Krug <r.m.krug@gmail.com>:

I finally started working on the implementation of grass commands from
R and most of the translation from the the output from
--interface-description is working. I just have one question at the
moment: some flags require "--" and others "-" and I could not fiind
any indication in the
--interface-description output which one uses which.

I guess, basically one-letter flags use '-' othewise '--', e.g.

      <flag name="g">
               <label>
                       Shell script style, currently only for report
               </label>
               <description>
                       Format: layer type count min max
               </description>
       </flag>
       <flag name="overwrite">
               <description>
                       Allow output files to overwrite existing files
               </description>
       </flag>

-> '-g' / '--overwrite' (or '--o')

I thought the same, but look at r.buffer --help:

Flags:
  -z Ignore zero (0) data cells instead of NULL cells
  -q Run quietly
--o Allow output files to overwrite existing files
--v Verbose module output
--q Quiet module output

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)

Plant Conservation Unit
Department of Botany
University of Cape Town
Rondebosch 7701
South Africa

[Paul_Kelly]

On Wed, 2 Jul 2008, Rainer M Krug wrote:

I finally started working on the implementation of grass commands from
R and most of the translation from the the output from
--interface-description is working. I just have one question at the
moment: some flags require "--" and others "-" and I could not fiind
any indication in the
--interface-description output which one uses which.

Any ideas where I can get that info from?

Flags that are interpreted by the GRASS module option parser and have a common meaning to all modules are prefixed by --. There is a fixed number of these (see lib/gis/parser.c for details). The interpretation of flags with a single - is defined by individual modules when they call G_parser() and the meaning of single - flags is individually dependent on each module.

I wonder if the special parser flags should be left out of the --interface-description output. Certainly they should be given a different name to distinguish them from the individual module flags - it's very confusing the way it is at the minute.

Paul