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