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

[Ivan Shmakov]

>>>>> Lucena, Ivan <ivan.lucena at pmldnet.com> writes:

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

 > HDFexplorer is a window based tool that gives you a good view of the
 > structure of a HDF4, netCDF and HDF5.

	How do I use HDFexplorer in, say, Shell scripts?

	Besides, is it available for GNU/Linux platform?

[...]

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

 > Let's imagine that you have a HDF file generated by a aerial photography
 > company that uses a multi-spectral camera. That is very unlikely to
 > happen (why they would choose HDF?) but if that happens it is very
 > certain that we are going to have problem with theirs files.

[...]

	Exactly.

 > In this case the user would need to create a helper file specific for
 > that HDF file (or for a groups of files). The "product" and "dataset"
 > name's value could be a simple wild card "*" meaning: for all
 > products and datasets that you might find here. We can keep the same
 > XML schema as the hdf-knowledge-base on <gdal>\data that I proposed
 > before. And yes, we can extend VRT for that.

	So far I have nothing against your proposal.

	However, it would be useful if the application could provide
	options to the driver without creating a helper file.  Consider
	running a web application (say, a kind of dataset explorer),
	which is, for the sake of security, restricted so that it cannot
	write any files.  It will be impossible for this application to
	allow user to specify any options for the GDAL driver not
	already in some helper file.  Allowing for options to be passed
	directly from the application to GDAL seems to solve this
	problem.

 > That will certainly requires a lot of changes in the HDF4 driver but
 > I am not sure how much difficult that changes would be comparing with
 > the Open Options alternative.

	I believe that the driver should be given options already read
	and parsed, and not the helper file name or its contents.  This
	way, both the options parsing and the whole options concept
	could be much generalized among the drivers.  And it requires
	introducing an ``options'' structure, which may be initialized
	either by GDAL reading the helper file, or by the calling
	application itself.