[gdal-dev] a generic options facility for GDAL

[Ivan Shmakov]

>>>>> Ivan Shmakov <ivan at theory.asu.ru> writes:

[...]

 > However, as I've stated before, different interfaces should be
 > provided.  There're a plenty of GDAL users with a wide variety of
 > needs.  There're tasks where encoding the options within the
 > dataset name would be appropriate, and the same for helper files
 > and separate options structure.

 > I believe, that these needs may all be addressed at once with a
 > generic options facility to be added to GDAL.

	I'm currently preparing a proof of concept patch implementing
	such a generic options facility for GDAL.  If all goes well I'll
	post it within 24 hours or so.

	In particular, it would be possible to override the dimensions
	order, and to specify the dimensions map (thus addressing ticket
	#2079, http://trac.osgeo.org/gdal/ticket/2079.)

 > To this end:

 > * upon ::Open (), GDAL parses the options encoded within the
 > dataset name; they result is passed to the specific driver;

	First version of the patch will probably implement only this way
	of passing the options, although a way to read them from a file
	(as specified by the dataset name) will be provided.  A way to
	selectively apply the options depending on the dataset name
	passed will be provided as well.

 > * upon ::OpenOptions (), application may pass additional options,
 > in addition to those already passed as specified above;

 > * the driver may request additional options from a driver-specific
 > helper file;

 > * all these options will become available to the parts of the
 > driver requesting them.

 > To my mind, the algorithm roughly outlined above covers well your
 > case, as well as, I believe, many other cases.

	After the patch will be ready, I'm going to evaluate it on my
	datasets, in particular on AIRS L2 and MODIS L3 BRDF/Albedo
	(MOD43B).  I'll post my experience (if any) some time later.