[gdal-dev] GDAL Java Bindings and HDF4 File format

[Sam Ritchie]

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.

Going off of my other answer, now -- am I correct in assuming that if I
build the source on a linux instance with "./configure
--with-hdf4=(hdf4path) --with-hdf5=(hdf5path)", 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't be so coupled to my particular system.

Also, point taken about that java file I linked to. I'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.

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'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'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.

On Tue, Jan 18, 2011 at 2:37 PM, Even Rouault
<even.rouault at mines-paris.org>wrote:

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