[GRASSLIST:6686] Re: libgrass as TGZ package
Roger.Bivand at nhh.no
Sat Apr 30 10:57:45 EDT 2005
On Sat, 30 Apr 2005, Markus Neteler wrote:
> On Sat, Apr 30, 2005 at 11:03:32AM +0200, Roger Bivand wrote:
> > I have the 1.2.6 release - I find the difficulties of interfacing multiple
> > changing codebases from CVS too great to be worth the trouble - keeping
> > all but one as released restricts blunders to my own code.
> Just a naive question:
> Why do you need the GDAL/GRASS plugin for the R interface?
> To test if R-gdal is an alternative to read GRASS data?
Yes, because maintaining a single code base is always better than
multiple, the bugs get found faster! Just as r.out.gdal reads the GRASS
raster database, rgdal in R could do the same, but more or less straight
into R. The current disadvantages are the region question, and how to pass
category labels (am I right that for GDAL, data are just numbers?).
> > > Do you get this number of GRASS libs?:
> > > ldd /usr/local/lib/gdalplugins/gdal_GRASS.so | grep grass | wc -l
> > > 6
> > $ ldd /usr/local/lib/gdalplugins/gdal_GRASS.so | grep grass | wc -l
> > 5
> I have
> ldd /usr/local/lib/gdalplugins/gdal_GRASS.so | grep grass
> libgrass_I.so => /usr/local/lib/libgrass_I.so (0x4001f000)
> libgrass_vask.so => /usr/local/lib/libgrass_vask.so (0x4002f000)
> libgrass_gmath.so => /usr/local/lib/libgrass_gmath.so (0x40035000)
> libgrass_gis.so => /usr/local/lib/libgrass_gis.so (0x4003b000)
> libgrass_datetime.so => /usr/local/lib/libgrass_datetime.so (0x400c0000)
> libgrass_gproj.so => /usr/local/lib/libgrass_gproj.so (0x400c8000)
The one I don't see is libgrass_gproj.so. My GRASS is the 6.0.0 release.
> > > > Do I need to re-install GDAL after having configured, built and installed
> > > > the plugin (I think not)?
> > >
> > > No.
> > So now on one of two RHEL 3 machines, it works, on the other not (but
> > maybe I need another ldconfig ...)
> I am working on RH7, RHEL 3 and Mdk10.0. Works everywhere.
> What is your "other" machine?
Both are RHEL 3, I think with the same PROJ.4, GDAL, R, and GRASS, but as
I said, I think it's just coincidence.
> > Thanks so far, it can be done, but it doesn't feel easy.
> Suggestions to improve things are always welcome.
> > Does r.out.gdal work under cygwin?
> Never tested, I have no idea. It should :-)
> > > > I'm keeping on about this because if this is this difficult to configure
> > > > for me, then the chances of any R/GRASS interface for GRASS 6 get very
> > > > slim - there are so many hoops to jump though even on Unix/Linux (not to
> > > > mention cygwin?) that no-one will ever use it.
> > > >
> > > > There do not seem to have been any downloads of the draft package from
> > > > sourceforge http://sourceforge.net/projects/r-spatial/ so far, so I've no
> > >
> > > I have added the link only last week to the GRASS site (unfortunately
> > > no other developer did it). So probably nobody was aware of it.
> > >
> > > I have downloaded it, so there must be at least 1 hit.
> > > Testing forthcoming. In fact I'll need ot soon, so I'll spend
> > > time on that.
> > Great, (sourceforge do warn that the counter isn't reliable). An example
> > of the use of the spgrass6 package is on http://r-spatial.sourceforge.net,
> > "sp and other packages" on the navigation bar on the left. The CVS code is
> > the freshest, but at least now sp is released and on CRAN, so the classes
> > used for holding data within R are becoming stable.
> > >
> > > > idea of whether any of this is actually required. GDAL and OGR provide
> > > > ways to prototype the interface cleanly. But then GDAL has to work both
> > > > ways, otherwise I can just stay with Arc ASCII grid files.
> > > >
> > > > What will help is a fool-proof installation route for getting r.out.gdal
> > > > to work like v.out.ogr does
> > >
> > > The "easy" solution is to write r.out.gdal in C. A long-standing wish...
> > >
> > Well, yes and no, because faster machines and discs are making scripted
> > loose coupling less of a problem time-wise. One problem I see with the
> > present script is that r.out.gdal seems to ignore the current region:
> > GRASS 6.0.0 (spearfish57):~ > g.region -p
> > projection: 1 (UTM)
> > zone: 13
> > datum: nad27
> > ellipsoid: clark66
> > north: 4928010
> > south: 4913700
> > west: 589980
> > east: 609000
> > nsres: 30
> > ewres: 30
> > rows: 477
> > cols: 634
> > GRASS 6.0.0 (spearfish57):~ > r.out.gdal soils type=Byte output=tmp/soils.tiff
> > Writing format: GTiff
> > Writing type: Byte
> > Input file size is 950, 700
> > 0...10...20...30...40...50...60...70...80...90...100 - done.
> > GRASS 6.0.0 (spearfish57):~ > gdalinfo tmp/soils.tiff | grep "^Size"
> > Size is 950, 700
> Yes, a known problem. This depends on the behaviour of the plugin
> which only sees the map but not the current region settings.
> Maybe a change there is useful:
> if in a GRASS session, then respect region, else read full map.
For me this is a scripting question on the R side - issue a system() call
from R to make a copy in GRASS with the correct region, read that, and
delete, so it is doable.
> > This differs from, for example, r.out.arc, which is what the draft
> > interface is using now. Is the only answer to use another operation to
> > resample first, then output through r.out.gdal - by the way, the same
> > applies to using rgdal within R to read from GRASS directly?
> I think so as it is using the same approach.
> A C implementation of r.out.gdal would certainly solve the problem.
> > Thanks for your patience!
> You are welcome!
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 at nhh.no
More information about the grass-user