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, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
