[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