[GRASS-user] Unable to load gdal library error

[Daniel Victoria]

On Thu, Sep 23, 2010 at 12:36 AM, Hamish <hamish_b at yahoo.com> wrote:
> Daniel wrote:
>> I compiled Grass 6.5 svn from source in Ubuntu 9.10 and it was
>> apperently working OK. I then loaded a bunch of srtm tiles using
>> r.external but, when I tried to patch them with r.patch I recieved the
>> message: ERROR: Unable to load GDAL library. I also cannot display the
>> srtm tiles imported using r.external in the Grass Map.
>
> no idea, but check that gdalinfo, gdalwarp, gdal_translate, etc still work.
>

It's strange cause I can use gdalinfo and gdal_translate on the SRTM
tif tiles and last night I patched them using gdal_merge.py. Also,
r.in.gdal works fine. And I can run r.info on the tiles imported using
r.external. But I can't display them or query the values (r.what also
gives ERROR: Unable to load GDAL library).

For the record, my GDAL configure line is:  --with-gdal=/usr/bin/gdal-config \
I have GDAL 1.7.2, released 2010/04/23 which I believe I got from the
ubuntu-gis repositories

>> However, I can iimport the srtm tiles using r.in.gdal and then raster
>> display works fine. My idea is to bring several SRTM tiles in grass
>> using r.external and then use r.patch. I was hopping not to use
>> r.in.gdal in order to save disk space...
>
> GDAL comes with a nifty little app called "gdal_vrtmerge":
>  swig/python/samples/gdal_vrtmerge.py
>

I was not aware of the vrtmerge function. Will give that a try, and
hope to identify what is wrong with r.external so I can reduce disk
space and speed things up. However, since I'll be running r.terraflow
on this huge SRTM image, would it be faster to import the image and
then run r.terraflow? Or use r.terraflow on a imaged linked using
r.external?

Cheers
Daniel

> if you feed it all your SRTM tiles, it will virtually patch them together,
> and then you can use gdal tools or r.in.gdal on the virtual mosaic.
>
> this is really great for running with "gdal2tiles" for an instant
> OpenLayers browser of all the data.
>  swig/python/scripts/gdal2tiles.py
>
>
> finally, if you put gdal_vrtmerge together with (a functioning..)
> r.external, you hardly have to take up any more disk space than the
> raw data files. Great for massive data caches where duplicates & disk
> space is an issue. If disk I/O is a limiting factor, probably it's faster
> to process too.
>
>
> Hamish
>
>
>
>
>