[gdal-dev] HDF-EOS vs. GDAL: order of dimensions

Andrey Kiselev dron at ak4719.spb.edu
Wed Dec 19 10:37:38 EST 2007


On Wed, Dec 19, 2007 at 09:18:29AM -0500, Lucena, Ivan wrote:
> But I also agree with Frank about the open options.

I hope we will develop some user-options solution for GDAL (and OGR) at
some point, because we need them for various drivers

> What if we create a hdf-knowledge-base, a simple XML helper file with
> details about particular HDF-EOS products?

On the first look I decided that it is a bad solution, but after some
thoughts it seems to be an interesting idea. Maybe we can use a virtual
datasets for this purpose in some way?

The big problem with this solution is a lack of resources on my side to
implement it. Another problem is that sometimes we can't identify the
product type of the HDF dataset.

> I understand the frustration of dealing with HDF. The format is great,
> the hdf library is good and the GDAL HDF4 driver is also good, but
> there is lack of documentation on the files itself so what usually
> happens is that we, programmers, read the documentation on the web and
> hard code it.

I am strongly disagree here. I am absolutely sure, that the HDF format
is bad. The format is only good for manual processing, but completely
unsuitable for automatic processing without user interaction. The
dimension order that we are discussing in this thread is just one
example of many problems with automatic processing of HDF. And HDF-EOS
adds even more troubles. In HDF-EOS data fields, dimensions,
geolocations and their relations with each other are marked with (sic!)
human readable names depicting the physical nature of that field or
dimension. It is totally unsuitable for generalization and automation.

> The question is: Can we cover all the issues about HDF4 and hard code
> then?

We can hardcode issues in driver (and we did), but it makes the driver
hard to maintain and refactor and it is endless source of bugs. One
workaroud can break something in another workaround and we can't catch
it, because it is impossible to have a test suite with all kinds of HDF
products and check for regressions everytime.

> Frank, Can you imagine using this "helper files" solution to other 
> situation and drivers?

What just came to mind: maybe we can pass options via the external file?
Via the PAM? Some info is being read from PAM files as of now, maybe it
could be a place for user controlled parameters?

Best regards,
Andrey

-- 
Andrey V. Kiselev
ICQ# 26871517


More information about the gdal-dev mailing list