[gdal-dev] GDAL Driver Changes

[Simon Perkins]

Frank Warmerdam wrote:
> I have made some changes to the way information about GDALDrivers is stored.
> GDALDriver's are derived from GDALMajorObject which automatically supports
> metadata, so I decided to store a bunch of info in the metadata.
> 
> The pszShortName is now the descriptions (accessed via the GetDescription()
> and SetDescription() methods). The rest of the values are stored as
> metadata.

Hi Frank,

While I think these changes are good, it does cause the slight
problem that the C++ API of GDAL, defined in gdal_priv.h has just
changed. As a result, some software I have that uses GDAL no
longer works. I can update my code to work with the new API, but
a more serious problem is how do I tell which version of the
library users have installed? Or should I not have relied on the
C++ API remaining constant? Are we supposed to use the C
interface only? Hopefully these API changes will happen rarely,
but if they do happen then we should try to retain backwards
compatibility. In this case that was probably impossible since
there was no C++ accessor function for the format short name.

Another small issue is that when I wrote the FITS driver for
GDAL, I wanted to handle reading and writing of arbitrary
metadata stored in the header. As a result, if you set items in
the metadata of a FITSDataset, then the driver will attempt to
write that information to the FITS file when the dataset is
closed. As it happens, that doesn't mess things up here since the
FITS driver only writes metadata with a key 8 or less characters
long, as required by the FITS format, so none of the new metadata
will get written by mistake (their keys are all longer than 8
chars). However, this is more through accident than design so I
should probably do something more sensible. Is this the kind of
problem that the "domain" field of the metadata was intended to
solve?

Just a few thoughts,

Sy




> I have also added MIMETYPE and EXTENSION metadata. The registration of the
> GeoTIFF driver demonstrates this fairly completely:
> 
> poGTiffDriver = poDriver = new GDALDriver();
> 
> poDriver->SetDescription( "GTiff" );
> poDriver->SetMetadataItem( GDAL_DMD_LONGNAME, "GeoTIFF" );
> poDriver->SetMetadataItem( GDAL_DMD_HELPTOPIC, "frmt_gtiff.html" );
> poDriver->SetMetadataItem( GDAL_DMD_MIMETYPE, "image/tiff" );
> poDriver->SetMetadataItem( GDAL_DMD_EXTENSION, "tif" );
> poDriver->SetMetadataItem( GDAL_DMD_CREATIONOPTIONLIST, "
> <CreationOptionList>
> <Option name='COMPRESS' type='string-select'>
> <Value>NONE</Value>
> <Value>PACKBITS</Value>
> <Value>JPEG</Value>
> <Value>LZW</Value>
> <Value>DEFLATE</Value>
> </Option>
> <Option name='INTERLEAVE' type='string-select'>
> <Value>BAND</Value>
> <Value>PIXEL</Value>
> </Option>
> <Option name='TILED' type='boolean' description='Switch to tiled format'/>
> <Option name='TFW' type='boolean' description='Write out world filet'/>
> <Option name='BLOCKXSIZE' type='int' description='Tile Width'/>
> <Option name='BLOCKYSIZE' type='int' description='Tile/String Height'/>
> </CreationOptionList>" );
> 
> Note that there is also the CREATIONOPTIONLIST metadata which is intended to
> be a description of all the creation options supported by a format. This
> is currently not being used for anything, but it is my intention to write
> a standard parser for the information and to do automatic validation in the
> generate GDALCreate() and GDALCreateCopy() code. This info can also be used
> to populate GUIs if/when that should be necessary.


-- 
Simon Perkins
Los Alamos National Laboratory, USA
http://nis-www.lanl.gov/~simes