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

[Lucena, Ivan]

Andrey,

You might be right, the dimension information on the subdataset string 
is a little bit of a stretch and it might not be the best solution for 
every situation. But I also agree with Frank about the open options.

User-case scenario: Right now I am facing problems with ImageServer (it 
uses GDAL to read HDF) and the only solution would be to get the latests 
updates on the HDF driver (or make my own changes to it), recompile and 
place it as a GDAL plugins on the path. That is not very user friendly :)

So, may I raise another suggestion if you don't mind?

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

That could have something like a list of products and dataset names and 
the particularities about then. So, a node on your XML could have:

product="MODISXYZ"
dataset="CLOUDSDATA"
processdate="20071001"

and then a set of particular issues about that dataset. That would 
include not only dimensions information but any other issue like "how to 
break down the bands of 16bits Quality data?", etc.

The file could be deployed at <gdal>\data but users should be able to 
create their own "hdf-helper" files and place in the same folder as 
their data or some kind of user-path.

Anyway, that is just a humble suggestion. 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. The question is: Can we 
cover all the issues about HDF4 and hard code then? If that is possible, 
forget about it.

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

Best regards,

Ivan

Andrey Kiselev wrote:
> On Tue, Dec 18, 2007 at 09:02:16AM -0500, Lucena, Ivan wrote:
>> Can we add the user-defined dimension request to the end of the 
>> subdataset name string?
>>
>> HDF4_SDS:subdataset_type:file_name:subdataset_index:user-defined-dimension
>>
>> Ex:
>>
>> gdalinfo HDF4_SDS:MODIS_L1B:my-hdf-file.hdf:2:134x2040
>>
>> That will not require any changes in the GDALOpen() API.
> 
> Personally I do not like this way. We already discussed the idea of
> separate option vs. filename encoding in regard to OGROpen() call and it
> also applies here. Though it seems I have not succeeded in convincing
> everyone that we should add open parameters to our open calls.
> 
> There is my thoughts on this topic:
> 
>  http://lists.osgeo.org/pipermail/gdal-dev/2007-November/014840.html
> 
> Note, that we already have format identification function in GDAL, so it
> applies only for OGR. Open options addition should apply both for GDAL
> and OGR.
> 
> Also I think it will be quite hard (or even impossible) to solve all HDF
> issues without user control.
> 
> Best regards,
> Andrey
> 
>