[gdal-dev] HDF5 metadata format problems

[Alex Mantaut]

Hi Frank:
            Thanks for your response. I wasn't sure if the whitespace was
allways going to be there, because for some fields had the white space but
others didn't. I will remove the trailing whitespace.

Now, I'm trying to develop a modification on the HDF5 driver to allow it to
get the georreference information from COSMO-SKYMED HDF5 files... The thing
is I'm not really familiar with the libraries used by GDAL(the use of
iostream is not allowed right?), what would be the better way to trim a
string? I looked into cpl_string and didn't found a simple way to do it (I
could use CSLTokenizeString() and get the first field on the list, but this
seems overly convoluted for a simple trim)

Also, is there any guidelines on which libraries to use on C++ in replace of
their std equivalents?

Thanks again
Alex




2011/6/13 Frank Warmerdam <warmerdam at pobox.com>

> 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
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 
--
     Alex Mantaut
SUR Emprendimientos Tecnológicos

Perú 345  Piso 5to Oficina "B" (C1067AAG)
Ciudad de Buenos Aires, Argentina
Tel. +54 (11) 4342-2976/84
javierurien at suremptec.com.ar
www.suremptec.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110614/2ab04153/attachment.html