[R-sig-Geo] Re: [GRASSLIST:5091] from adehabitat to grass

[Roger Bivand]

On Thu, 9 Dec 2004, Paolo Cavallini wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi all.
> 
> For the project AniMov [1] we are trying to export R objects of class "area" 
> from adehabitat [2] for use in GRASS 5.7 (immage at: 
> www.faunalia.com/animov/area.png).
> We tested the following paths:
> 1. use dxf as an exchange format: this does not work, because the format is 
> dxf, which requires a non-free library, and the recompilation of grass
> 2. use the modules for writing shapefiles (area2shape and export.shape) from 
> Clement Calenge (the author of adehabitat). Resulting shapes can be read by 
> qgis [3], but not by grass, for unknown reasons (see a sample at: 
> www.faunalia.com/animov/test1.zip); there might be something wrong here, 
> because also using the library "shapefiles" importing and exporting a valid 
> shapefile we get the same result (sample at: 
> www.faunalia.com/animov/test2.zip).

Neither of the R functions you mention: area2shape() and export.shape(), 
are in packages ade4 or adehabitat. Using the R maptools package, your 
test1.* and test2.* are readable (so readable with shapelib), but test1.* 
has overlapping polygons. If we could convert "area" objects to the 
current "polylist" or future package sp representations, the 
write.polylistShape() function (using shapelib) in maptools could be used.

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

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

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

Best wishes,

Roger

> 
> All the best.
> 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
> ============================
> [1] http://www.faunalia.com/animov/
> [2] http://cran.r-project.org/src/contrib/Descriptions/adehabitat.html
> [3] http://qgis.org/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> 
> iD8DBQFBuD1j/NedwLUzIr4RAt2TAJ0RT27MmMYSVsOiVlgi4p9O15xUoQCfbF/7
> OTi8XCZOJUkzqIMTN/GvVVE=
> =JAl/
> -----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