Even, great point, and of course this makes sense, as the java bindings simply refer to these other libraries. My other reply explains what should have been my initial question, I suppose.<div><br></div><div>Going off of my other answer, now -- am I correct in assuming that if I build the source on a linux instance with &quot;./configure --with-hdf4=(hdf4path) --with-hdf5=(hdf5path)&quot;, and generate the native dependencies from that source code, I can rely on the java bindings working for any machine where the hdf4 and hdf5 libraries sit at the same path? This would probably work great, and would allow me to post the results for anyone interested, as it wouldn&#39;t be so coupled to my particular system.<br>

<div><br></div><div>Also, point taken about that java file I linked to. I&#39;ve just realized that the swig/java/apps/gdalinfo.java is more up to date. I really only needed to copy that file up until the Open() step, just to make sure that was all working fine.</div>

<div><br></div><div>I can now read HDF4 locally; the next step is to think about a package that I can deploy on EMR. The reason for this is that I&#39;d like to be able to run a single jar file for my whole MapReduce flow. This requires me to keep the dependencies for that jar quite minimal -- I can&#39;t bundle up gdal, but if I can at least bundle the bindings, and their native dependencies for each architecture, then I should be able to release this tool to the community.</div>

<div><br><div class="gmail_quote">On Tue, Jan 18, 2011 at 2:37 PM, Even Rouault <span dir="ltr">&lt;<a href="mailto:even.rouault@mines-paris.org">even.rouault@mines-paris.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Le mardi 18 janvier 2011 20:20:05, Sam Ritchie a écrit :<br>
<div class="im">&gt; Hey all,<br>
&gt;<br>
&gt; Short question first, then the longer explanation.<br>
&gt;<br>
&gt; *QUESTION*: My java SWIG bindings, generated from source, can&#39;t read the<br>
&gt; HDF4 format. How can I fix this?<br>
<br>
</div>Sam,<br>
<br>
The fact that you can&#39;t read HDF4 files is very likely unrelated with the use<br>
of the Java bindings. You should concentrate on making GDAL standard command<br>
line utilities, such as gdalinfo, to recognize your HDF4 file first.<br>
<br>
Does gdalinfo --format HDF4 returns something like :<br>
<br>
Format Details:<br>
  Short Name: HDF4<br>
  Long Name: Hierarchical Data Format Release 4<br>
  Help Topic: frmt_hdf4.html<br>
<br>
This would be a sign that your GDAL build is correctly configured.<br>
<br>
If so, you can try &quot;gdalinfo yourfile.hdf&quot;. If it works, you can then move on<br>
the Java side. If not, well, you&#39;ve got a file that isn&#39;t handled by the HDF4<br>
driver and this would probably deserve a Trac ticket with a link to it.<br>
<br>
I&#39;d node that <a href="https://svn.osgeo.org/fdo/tags/3.4_G032/Thirdparty/gdal" target="_blank">https://svn.osgeo.org/fdo/tags/3.4_G032/Thirdparty/gdal</a> isn&#39;t<br>
the official repository of GDAL. It looks like an import of GDAL 1.6.0 made by<br>
the FDO project. I&#39;d encourage you migrating to GDAL 1.7.3 or the soon-to-be-<br>
released GDAL 1.8.0 as many bugfixing occured in the Java bindings starting<br>
with GDAL 1.7.0.<br>
<br>
Best regards,<br>
<font color="#888888"><br>
Even<br>
</font></blockquote></div><br></div></div>