[GRASSLIST:5100] Re: from adehabitat to grass

Roger Bivand Roger.Bivand at nhh.no
Thu Dec 9 13:15:48 EST 2004


On Thu, 9 Dec 2004, Paolo Cavallini wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> At 15:11, giovedì 09 dicembre 2004, Roger Bivand has probably written:
> > A current effort in R is to establish foundation classes - which will let
> > us have many-to-one, one-to-many converters. So a first step will be to
> > convert area to some such class, then write that as a polygon shapefile.
> > Which GRASS shapefile reading program are you using (which version)?
> 
> gdal 1.2.1 (as from debian testing)

So that is the same as shapelib, effectively.

> 
> > > I believe it would be better to import "area" objects directly, but the
> > > module R-GRASS apparently cannot do that. Is there any suggestion?
> >
> > No, not "area" class objects. Then we get many-to-many. It is much better
> > to reduce to a single foundation class set first, then the interface would
> > work for all points, lines, polygons, etc., without having to write a
> > separate interface for each R class.
> 
> Quite right.
> 
> > For vector, it will be some time before the GRASS libaries are as stable
> > as raster is and sites were, so using loose coupling through files is more
> > robust for now. 
> 
> However, grass 6.0 is on its way. I do not think vector format is going to 
> change again (not very soon, however). Maybe Radim has a word here?
> 

Compared to reading and writing rasters to the GRASS database, there seem 
to be many more variants, so finding the right level of generalisation is 
important. The interface code will need to grab the data GRASS -> R where 
it is least divergent (uniform internal representation irrespective of how 
it is held), and insert R -> GRASS data at the same place. I don't use 
5.7, keeping up with 5.0 -> 5.4 is sufficient trouble, even libes/gis is 
still full of traps for interfaces because the interface stays "alive" 
much, much longer than regular GRASS programs. 

An example: the interface's view of the current region had to be adapted
to react appropriately to a user calling system("g.region") - the code in
libes/gis caches the information, but doesn't update it, so the interface
"sees" the old window in cache, not the actual window, because the GRASS 
libraries were thought of as being used in programs that run strictly one 
after another, not being alive at the same time. That is why an 
interpreted interface just using system() in R within GRASS is a good 
place to start, because the programs init() and exit(), and don't stay 
alive, even though this can be much slower.

> > The interface can be extended to do this using system() in 
> > R. Is it worth putting a "new generation" R/GRASS interface based on the
> > current one on sourceforge?
> 
> Surely starting the work on this would be important.

Well it might be done if there were contributions, which was why I 
suggested sourceforge. Putting the current code there is not sensible - I 
need first to contribute changes to libes/gis to give the interface the 
handles it needs to stop being stomped on, then build the interface not 
standalone but linked to GRASS libraries (as in the first compiled 
versions which were something of a nightmare to get right on 
Windows/cygwin), then release to sourceforge. I don't see Radim or 
Markus getting lots of help coding the 5.7/6.0 vector stuff, that's the 
bottleneck here, people contributing actual code that works and adresses 
central issues (though in other areas a lot of good work has been done 
recently by other developers).

This is actually very related to your other post about loadable modules 
and the R contributed package mechanism - in R, the framework exists for 
less central packages to be contributed, and that lets the core team focus 
more on core issues. I do feel that people who want to contribute should 
understand that, for data analysts, learning to program in at least a 
scripting language is something they will benefit from anyway.

As I wrote yesterday on GRASSLIST in reply to Miha Staut, contributions of
GRASS 5.7/6.0 scripts for reading and writing shapefiles would make it
easier to start work, once the foundation classes for vector stuff are in
place in R (r-spatial on sourceforge, releases are outdated, use cvs only,
point/grid/cell is OK, polygon/line not yet).

So, if I put the R/GRASS interface on sourceforge under r-spatial or as 
another project, who will want to join as a developer?

Roger

> 
> Thanks a lot.
> pc
> - -- 
> Paolo Cavallini
> cavallini at faunalia.it   www.faunalia.it   www.faunalia.com
> Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy   Tel: (+39)348-3801953
> http://pkg-grass.alioth.debian.org/cgi-bin/wiki.pl
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> 
> iD8DBQFBuGda/NedwLUzIr4RArqeAJ9W2fU9Y0VchlQcTWDcwFwonneIwgCeOR7G
> E8jE46o9vk+/yoSp0bDWl4A=
> =e09b
> -----END PGP SIGNATURE-----
> 
> 

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







More information about the grass-user mailing list