[gdal-dev] HDF5 metadata format problems

[Frank Warmerdam]

On 11-06-13 04:53 PM, Alex Mantaut wrote:
> Hi all:
>          I've ran into some troubles while trying to interpret an HDF5's
> metadata...
>
> Every field on HDF5 has it's own type(string, uchar, double) But
> GetMetadataItem("field_name")  converts the data from the dataset into a
> C-style zero terminated string.
>
> This gives me a few problems:
>
>   a-This string has a trailing space for some datatypes, but not for others (in
> unsigned char there is no space) ... There is no comment in the driver's code
> explaining if this is necesary or not(hdf5dataset.cpp from line 661)... I need
> to know if there will allways be a trailing space or not, to be able to perform
> type conversion on the data...

Alex,

I don't quite grasp why you need to know if there will be a trailing
space.  I see the spaces are being appended as a separator in the hdf5
driver in case the value is actually an array of values.  I would suggest
you just strip off trailing white space in your client code if it is an
issue.

> b-Some items are type double and have more than 6 digits on the integer part,
> but the string show the output in exponential notation, that makes me lose some
> significant digits...
>
> I looked into the code and the problems seems to be on hdf5dataset.cpp on line
> 744, and changed the type on sprintf() from %g to %f, But now the number of
> decimal digits is fixed, which could bring me similar problems when using
> doubles... The question is: Is there a convention on how many
> decimal digits you have to show on the string? there could be another way to
> return a number from an item that doesn't truncate the digits?

To preserve precision it is normal to format these as %.15g.  I believe
this does a pretty good job of preserving double precision floating point.

I have changed the float and double code to use this format in trunk and
1.8 branches.

> Given all this problems i wonder: Could somebody provide a way to retrieve the
> data in it's binary form with maybe some information on the metadata's type? or
> this would only be usefull on the HDF5 format?

This would be a substantial change to the metadata handling mechanism in
GDAL and is unlikely to occur.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent