This post describes the setup of the Java bindings of GDAL. The basic idea was that I wanted access to other image formats, in particular ENVI, without writing a bunch of code to slice and dice the binary blobs in which ENVI stores image data. There are a lot of ways to wrap the GDAL binaries from scratch. For some examples, see here: http://trac.osgeo.org/gdal/wiki/GdalOgrInJava
Call it laziness, but I just did not want to deal with SWIG and having to re-compile everything. I suspected there is an easier way and there is. Good tech samaritan Tamas Szekeres maintains this list of pre-compiled binaries, including wrappers: http://vbkto.dyndns.org/sdk/
So I downloaded this one, for my Windows XP 32-bit operating system: release-1600-gdal-1-8-mapserver-5-6 which is compiled with Microsoft Visual C++ 2010. In the install directory is a GDAL/java/gdal.jar file. I would like to make use of this from within the Eclipse IDE. So I add gdal.jar to the class path and try to gdal.AllRegister(); But I get an exception like:
Native library load failed. java.lang.UnsatisfiedLinkError: C:\Program Files\GDAL\gdaljni.dll: Can't find dependent libraries
So I add the following to the VM arguments:
This got me a little further but still threw an UnsatisfiedLinkError. Tamas suggested that I download the Microsoft Visual C++ 2010 Redistributable Package: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=a7b7a05e-6de6-4d3a-a423-37bf0912db84
Once this was installed, gdal.AllRegister() runs without an exception, even if I remove the virtual machine argument. The GDAL test code also runs (GDALtest.java, GDALTestIO.java) no problem (given the data types that are checked in the code). I have now made a similar installation on a Windows 7 64-bit OS that works. However, I did discover that if GeoTools 2.7 is installed (with imageio-ext 1.0.6), GDAL and GeoTools will not play well together. As soon as I took GeoTools off the classpath, everything worked fine. Otherwise, I got an UnsatisfiedLinkError. Out of superstition, I also added the location of the GDAL binaries to the system "path" variable, just in case windows starts hunting around for something.
The other thing that I have experienced on both XP and Windows 7 is that the JNI wrapper broke, possibly after a recent update. After some gnashing of teeth, a reinstallation of either the VC++ redistributable or GDAL, everything started working again.