[Gdal-dev] FITS Metadata Change
Simon Perkins
s.perkins at lanl.gov
Mon May 5 14:57:47 EDT 2003
Hi,
This is only of possible interest to people who use the FITS driver in
GDAL...
I want to commit a small change (AKA fixing a small design flaw) to the
way metadata is handled for the FITS driver. I don't know if anyone else
is using this driver and probably even if you are this change will have
no effect, but just in case...
The essence of the change is to with the way that GDAL metadata is
mapped onto the underlying metadata that FITS files support. Both types
of metadata consist of key/value pairs where the key is a string. In
GDAL, the value is also always a string, but in FITS, the value may be
of arbitrary type and the FITS standard specifies that these different
types should be physically stored in different ways. To try to follow
this standard, the current GDAL FITS driver inspects the GDAL value
string and then tries to guess what type of data it represents. It then
uses the appropriate method to write the metadata.
Trouble is, it can guess wrong. For instance a version number might have
significant leading zeros that would be stripped off if the value is
treated as a numeric one. So I'm proposing to revert to a simpler scheme
where all values are stored as strings. Pure GDAL users will not notice
any difference. People using the standard CFITSIO library to read GDAL
written files will also not notice a difference since that library does
automatic type conversions. People assuming that a metadata value
written under GDAL will appear in the file in a specific physical way,
might have problems. If you're in this final category, let me know!
Otherwise I'll commit the change to CVS sometime soon.
Cheers,
Sy
More information about the Gdal-dev
mailing list