Re: [GRASS-user] Unable to load gdal library error
Daniel Victoria wrote: 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). That error message indicates a failure to load the GDAL library at run time via dlopen(). r.in.gdal is linked against GDAL, and r.info doesn't need access to the raster data. You will only get the error from modules which attempt to access the raster data for a linked map created with r.external. The code which loads the library attempts to dlopen() each of following names in turn: libgdal.1.1.so gdal.1.0.so gdal.so.1.0 libgdal.so.1 libgdal.so If none of the attempts succeed, you get the above error. The library must be listed in /etc/ld.so.cache (generated by ldconfig) or in one of the directories in $LD_LIBRARY_PATH. Also, it must have complete dependency information, and all of its dependencies must be satisfied. -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Unable to load gdal library error
On Sat, Sep 25, 2010 at 7:57 AM, Glynn Clements gl...@gclements.plus.com wrote: Daniel Victoria wrote: 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). That error message indicates a failure to load the GDAL library at run time via dlopen(). r.in.gdal is linked against GDAL, and r.info doesn't need access to the raster data. You will only get the error from modules which attempt to access the raster data for a linked map created with r.external. The code which loads the library attempts to dlopen() each of following names in turn: libgdal.1.1.so gdal.1.0.so gdal.so.1.0 libgdal.so.1 libgdal.so If none of the attempts succeed, you get the above error. The library must be listed in /etc/ld.so.cache (generated by ldconfig) or in one of the directories in $LD_LIBRARY_PATH. Also, it must have complete dependency information, and all of its dependencies must be satisfied. I guess it's a library naming problem then because what I have inside ld.so.chache is: dan...@xadrez:/etc$ sudo ldconfig -p | grep gdal libgdal1.7.0.so.1 (libc6) = /usr/lib/libgdal1.7.0.so.1 libgdal1.7.0.so (libc6) = /usr/lib/libgdal1.7.0.so libgdal1.6.0.so.1 (libc6) = /usr/lib/libgdal1.6.0.so.1 dan...@xadrez:/etc$ Also, I don't have any of the lib names mentioned by Glynn in /usr/lib, as you can see bellow. dan...@xadrez:/usr/lib$ ls *gdal* libgdal1.6.0.so.1 libgdal1.7.0.a libgdal1.7.0.so.1 libgdal1.6.0.so.1.13.3 libgdal1.7.0.so libgdal1.7.0.so.1.14.2 gdal16plugins: gdal_GRASS.so ogr_GRASS.so gdal17plugins: gdal_GRASS.so ogr_GRASS.so So, by linking libgdal.1.1.so to libgdal1.7.0.so everything came back to normal... Well, sort of... Now, when I try r.what on the raster I get... WARNING: category support for [srtm_21_12] in mapset [PERMANENT] missing ERROR: Unable to read category file of raster map srtm_21_12 in PERMANENT For the record, this is part of the r.info output of the srtm tile: Type of Map: raster Number of Categories: ?? | | Data Type:CELL | | Rows: 6001 | | Columns: 6001 | | Total Cells: 36012001 Cheers Daniel Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Unable to load gdal library error
Daniel wrote: Tried recompiling grass but that did not change anything. So I ran ldd `which r.what` and it did not show any links to a gdal library... This is what I got GRASS 6.5.svn (br_wgs84):~ ldd `which r.what` linux-gate.so.1 = (0x00f71000) libgrass_gis.so = /usr/local/grass-6.5.svn/lib/libgrass_gis.so (0x00a31000) libgrass_datetime.so = /usr/local/grass-6.5.svn/lib/libgrass_datetime.so (0x00c02000) libz.so.1 = /lib/libz.so.1 (0x002ca000) libm.so.6 = /lib/tls/i686/cmov/libm.so.6 (0x00681000) libc.so.6 = /lib/tls/i686/cmov/libc.so.6 (0x00d3d000) libdl.so.2 = /lib/tls/i686/cmov/libdl.so.2 (0x00ace000) /lib/ld-linux.so.2 (0x005a5000) GRASS 6.5.svn (br_wgs84):~ Does this means that I messed up during compilation? no, just that a library calls gdal not the module. try: ldd /usr/local/grass-6.5.svn/lib/libgrass_gis.so Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Unable to load gdal library error
On Thu, Sep 23, 2010 at 12:36 AM, Hamish hamis...@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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Unable to load gdal library error
Daniel wrote: r.external [...] ERROR: Unable to load GDAL library. .. 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). try ldd `which r.what` and examine if the GDAL library versions are consistent with what you think it should be using (`gdalinfo --version` and ldd `which gdalinfo`) if gdal was upgraded after grass was built, grass may need to be rebuilt against the new version of gdal.. However, since I'll be running r.terraflow on this huge SRTM image, MMetz will suggest you try the new r.watershed too :-) would it be faster to import the image and then run r.terraflow? probably. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Unable to load gdal library error
Hi list, 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. 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... Why is it that r.in.gdal works but r.external don't? Thanks daniel ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Unable to load gdal library error
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. 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 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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
