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

Andrey Kiselev dron at ak4719.spb.edu
Wed Dec 19 13:27:01 EST 2007


On Wed, Dec 19, 2007 at 11:17:34PM +0600, Ivan Shmakov wrote:
> 	Other issue is the lack of tools to process generic HDF files.
> 	I've never seen a tool which allows for an HDF file to be viewed
> 	as a sort of ``dataset archive'' (which it, essentially, is),
> 	allowing for certain datasets to be added to, removed from or
> 	moved between HDF files.  (Not to talk about obtaining subsets,
> 	merging, changing the order of the dimensions, etc.)

Yep, because such a tool should expose the whole hdflib API in its
interface to be flexible enough for all sorts of HDF. It is non-trivial
to create such a tool and it is even more non-trivial to make its
over-complicated interface usable.

>  > 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.
> 
> 	Besides, what you'd recommend to the users should a brand new
> 	HDF-EOS product to emerge?  I'm certain that ``updating from the
> 	SVN trunk'' is barely an option, at least for some users.
> 	Giving user more control over how the data is to be interpreted
> 	is the solution.

Exactly, that is waht I am talking about. I would like to move to user
as much control as possible.

Best regards,
Andrey

-- 
Andrey V. Kiselev
ICQ# 26871517


More information about the gdal-dev mailing list