-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/01/12 22:19, Hamish wrote: > Rainer wrote: >> I am writing to you directly, as you are the author of the >> r.out.mat. > > dangerous! my inbox is flooded and I might easily miss it :) >
OK - I'll push it to grass-stats - that others can get involved. >> I have a simulation, which heavily relies on reading and writing >> spatial data from GRASS into R and vice versa. Profiling >> indicated, that the actual readRAST6() from R takes uip a large >> proportion of the simulation. So I looked into alternatives, and >> as it is not that difficult to return data from C to R, I thought >> about that option. > > please post to the statsgrass mailing list. Roger Done > may have a good idea about what to do. ISTR there were two > options, and older & slower but more compatible way and a newer and > faster way. you could select them via a switch. maybe your system > is using the old+slow way? I tried out with the useGDAL option TRUE and FALS, aned the plugin is not installed on the cluster where I finally want to run the simulation (and, in addition, I would like to avoid GDAL doe to continueing hassles wth isnstalaltions etc. on the cluster - locally GDAL works nicely) I actualy did some benchmarks between useGDAL TRUE and FALSE and there was a difference in the 10% range, but still not fast enough. > >> The module r.out.mat actually extracts all the data from GRASS >> and saves it (spatial header information and the actual map >> data). > > r.out.bin would be more appropriate, as Matlab format saves > column-wise not row-wise due to its Fortran origins, so you have > to read the entire map into memory, which doesn't work for massive > datasets. Thanks - I'll look at that one. The "part of map" is a useful consideration. > > both are very simple, see doc/raster/r.example/ in the source > code. no need for libraries or anything. > > > header data is available from r.info flags and $MAPSET/cellhd/ The thing is I would like to avoid using files and access GRASS maps as directly as possible, which, as I understand it at the moment, would be via C function(s) in GRASS whose return values are the data, and a C function(s) in R which calls these GRASS C functions to provide the data to R. > > > the alternate idea is to use R's gdal package to read the GRASS > raster maps directly. As mentioned earlier, I would like to avoid GDAL doe to installation problems - but I should try this. I understand that the idea of GDAL is to convert spatial data between different formats, but there is (as far as I now) no way to get GASS data directly into R, without creating an intermediate format, so GRASS (disk) --> GDAL (memory) --> new format (disk) --> R resulting in reading from disk, converting, writing to disk and reading the converted data again. No problem if I am doing analysis, but if I am running my simulation model, data is read and written to GRASS all the time, and this intermediate step costs lots of time. I could do some benchmarks with the spearfish dataset next week to show what I mean. Cheers and thanks, Rainer > > > double check your region bounds and resolution are correct, or it > could waste a lot of time. I'll do, but I am 99% sure that they are correct and as I need them. > > > regards, Hamish - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D): +49 - (0)3 21 21 25 22 44 email: [email protected] Skype: RMkrug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8RR30ACgkQoYgNqgF2ego03gCeK5DhbC1TQzgVM7OdBMwvqR+u JoUAniH8s9j0HLb3KafkqoAU6SYNRbcl =+gkB -----END PGP SIGNATURE----- _______________________________________________ grass-stats mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-stats
