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

[Lucena, Ivan]

Guys,

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

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

> 	Agreed completely.  Though, in my opinion, it's not the fault of
> 	the HDF format per se.

So I guess we can call 90% of HDF accidents human error.

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

- The HDF4 type could be SDS, Grid, Swath or Point.

- The "product" will not going to match with any known HDF products. The 
same thing with the "dataset" names.

- The "dataset"s are going to be multi-dimensional but we don't know in 
witch order it will come. X,Y,Z if we are lucky. (YYZ if you like Hush).

- The ground control points could be stored as Swath geolocation or 
SDS/Grid "dataset" with names like "east/south".

- Hum.. What else can go wrong here? Anyway,

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.

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.

Best regards,

Ivan