r.in.gdal [was Re: [GRASS5] STDS(DEM)2ASC and Possible Bug]
Eric G . Miller
egm2 at jps.net
Wed Jan 17 00:45:35 EST 2001
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.
1. I vote we just publish a final GRASS 5.0 real soon. We'll just be
upfront about outstanding bugs (Note: we *really* need to turn off that
LZW code then... seems most the other license/patent issues have been
moved out of main src/compile tree).
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?
Eric G. Miller <egm2 at jps.net>
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