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

[Ivan Shmakov]

>>>>> Andrey Kiselev <dron at ak4719.spb.edu> writes:

 >> However, are there any reasons to actually disallow options to
 >> be specified in the (sub)dataset name?

 > I think this way is counter-intuitive and error-prone:

 > http://lists.osgeo.org/pipermail/gdal-dev/2007-November/014853.html

	I agree with your point.

	However, my opinion is that the specification of options via the
	dataset name should be allowed for both the sake of
	compatibility and for the user convenience.

	It won't take any extra effort from the driver developer,
	provided that the concept of options will be generalized and a
	generic options parsing routine will be implemented for GDAL.

	To make it clear:

	* the driver should be given options already parsed;

	* it's GDAL that should do the parsing, and it may parse both
	  the helper file and the dataset name without introducing any
	  extra burder to the driver;

	* the application should be provided a way to specify the
	  options directly, without having to encode them into either
	  the helper file or the dataset name.

 >> Indeed, I've been thinking about a kind of ``helper files''
 >> (though a somewhat different kind) to allow for specified
 >> datasets to be ``stacked upon each other along the band axis'',
 >> forming a dataset with the same spatial dimensions and a larger
 >> bands number...

 >> BTW, setting GCPs and specifying the projection fits quite
 >> neatly into the ``helper file'' framework.  I'm sure there are
 >> many other applications for them.

 > Actually it can be done with help of VRT datasets.

	May be it's the time for me to take a look at these.