r.in.gdal [was Re: [GRASS5] STDS(DEM)2ASC and Possible Bug]

Markus Neteler neteler at geog.uni-hannover.de
Wed Jan 17 04:36:45 EST 2001

On Tue, Jan 16, 2001 at 09:45:35PM -0800, Eric G . Miller wrote:
> On Wed, Jan 17, 2001 at 12:08:59AM -0500, Frank Warmerdam wrote:
> > For what it's worth, r.in.gdal will read SDTS DEM files directly to GRASS
> > raster if GDAL is setup properly.  I just downloaded the binary distribution,
> > ensured I had a /usr/local/lib/libgdal.1.1.so installed, and it worked fine.
> > 
> > Markus - I would like to include libgdal.1.1.so in the pre-built 
> > distributions, at least the Linux one.  When are you thinking of doing
> > a beta 11 or final 5.0 release?  To make this work smoothly I would like
> > to have the libgdal.1.1.so just distributed in the grass5 tree, perhaps
> > /usr/local/grass5/lib, and to slightly update r.in.gdal to look there
> > as well as the usual locations. 

[another mail...]

> 2.  Re: r.in.gdal.  libgdal has several dependencies above what GRASS
> already relies on.  I think it would be a good inclusion, but I think we
> might have difficuly meeting all the dependency requirements.  I found
> it less than trivial to get libgeotiff compiled, for instance, since it
> wanted to live in a certain place with respect to libtiff sources and 
> requires private headers.  I don't think it's [libgeotiff] ubiquitous
> enough to be able to rely on it (though it certainly is desirable).
> Perhaps there's some minimal set of requirements that would still
> preserve it's [r.in.gdal] utility?

I would be glad if GDAL is included as it reduces the extra work
for the users. For GRASS 5.1 I proposed a "plugin" directory (maybe
only for the binaries) to place extra libs there.


If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'

More information about the grass-dev mailing list