[GRASSLIST:6686] Re: libgrass as TGZ package

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.

Roger

> 
> > 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!
> 
>  Markus
> 

-- 
Roger Bivand
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