[GRASSLIST:6685] Re: libgrass as TGZ package

[Markus Neteler]

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?

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

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

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

> 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