[GRASSLIST:6684] Re: libgrass as TGZ package

Sat Apr 30 05:03:32 EDT 2005

On Fri, 29 Apr 2005, Markus Neteler wrote:

> On Fri, Apr 29, 2005 at 06:31:20PM +0200, Roger Bivand wrote:
> > On Fri, 29 Apr 2005, Markus Neteler wrote:
> > 
> > > On Fri, Apr 29, 2005 at 02:45:21PM +0200, Roger Bivand wrote:
> > > > On Fri, 29 Apr 2005, Markus Neteler wrote:
> > > > > On Wed, Apr 27, 2005 at 04:58:43PM +0200, Rado Bonk wrote:
> > > ...
> > > > > But the recommended method is to use the GDAL/GRASS
> > > > > plugin. Compilation order:
> > > > > 
> > > > > - GDAL without GRASS support (you may have to actively disable
> > > > >   it using the appropriate configure switches)
> > > > > - GRASS 6
> > > > > - GDAL/GRASS plugin
> > > > > 
> > > > > Configure scripts can be grabbed here:
> > > > >  http://mpa.itc.it/markus/useful/index.html
> > > > > 
> > > > >  ->  conf_gdal.sh
> > > > >  ->  conf_grass61_linux.sh
> > > > >  ->  conf_install_gdal_grass_plugin.sh
> > > > 
> > > > Well, after having done this, and:
> > > > 
> > > > $ ls -l /usr/local/lib/gdalplugins
> > > > total 36
> > > > -rwxr-xr-x    1 root     root        34606 Apr 29 14:32 gdal_GRASS.so
> > > > 
> > > > (the script presupposes that the user running it has access to 
> > > > gdalplugins)
> > > 
> > > Well, the plugin has to be installed along with GDAL. So
> > > probably root permissions are needed.
> > 
> > Yes, but then two scripts would be needed, one for ./configure and make, 
> > one for make install ...
> 
> Yes.
> I didn't intend to provide all-in-one solutions - moreover
> the suggested scripts are an offer to figure out the parameters.
> 

Accepted.

>  
> > > 
> > >  
> > > > I still can't see any access:
> > > > 
> > > > $ gdalinfo ~/topics/grassdata/spearfish60/PERMANENT/cellhd/geology
> > > > ERROR 4: `/home/rsb/topics/grassdata/spearfish60/PERMANENT/cellhd/geology' 
> > > > not recognised as a supported file format.
> > > 
> > > OK - a couple of tests:
> > > 
> > > - which GDAL version are you using? The search patch changed.
> > >   If you have an "older" GDAL, try to move the plugin to
> > >   /usr/local/lib/ (where libgdal.so stays)
> > > 
> > 
> > 1.2.6 from the tarball compiled 29 April, is this "older"?
> 
> The GDAL ChangeLog says:
> 
> 2005-04-22 15:40  fwarmerdam
> 	* frmts/grass/pkg/configure.in: Default for autoload path is
> 	$prefix/lib/gdalplugins now.
> 
> Do you have 1.2.6 or 1.2.6-CVS? 1.2.6 was released in March, so it's older.
> The current CVS is using the new scheme.

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.

> 
> > > - if this works, congrats (keep in mind that /usr/[local/]lib/gdalplugins
> > >   is the new home
> > 
> > It doesn't work.
> 
> So you seem to have a "new" GDAL.
> 
> 
> > > - if this doesn't work, move the gdal_GRASS.so back to
> > >   /usr/local/lib/gdalplugins/
> > > 
> > > - then
> > >   ldd /usr/local/lib/gdalplugins/gdal_GRASS.so  | grep grass
> > >   
> > >   Does it find the GRASS libraries? If not, 
> > 
> > No, it didn't find them.
> 
> OK, we are close:
>  
> > >    - either add their path to /etc/ld.so.conf
> > >    - or link the GRASS libs into /usr/local/lib (this is what I do)
> > 
> > I did this, ldd reports that they are present (after an ldconfig), but 
> > gdalinfo still doesn't recognise the file in cellhd (neither inside nor 
> > outside GRASS). 
> 
> Here it will not (!) be listed as the plugin is loaded run-time:
>  ldd `which gdalinfo` | grep grass | wc -l
>      0
> Correct value.

$ ldd `which gdalinfo` | grep grass | wc -l
      0

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

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

Thanks so far, it can be done, but it doesn't feel easy. Does r.out.gdal 
work under cygwin?

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

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?

Thanks for your patience!

Roger

> > - I've no idea how the GDAL programs are 
> > supposed to find the plugin (I can understand that they know about formats 
> > they were compiled with, but how should a plugin be regisered in GDAL if 
> > is is built after GDAL itself?).
> 
> http://xserve.flids.com/pipermail/gdal-dev/2005-March/008227.html
> "It is documented deep in the api ref docs at:
>   http://www.gdal.org/classGDALDriverManager.html#a8
> "
> 
> Good luck!
> 
>  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