Re: [gdal-dev] RE: How to get some special metadata of HDF5 Cosmo-Skymed file
I'm not sure if I understood your problem... You can't find the
Calibration Constant?
In that case the calibration constant is a property of the Sxx group.
Check csk-product handbook page 45 for more information.
Hope it helps!
Regards
2011/7/11 RSyaoxin rsyao...@hotmail.com:
Thanks Alex Mantaut .This document is what I previously reference.Maybe the
problem is that I do not know how to extract Calibration ConstantorK
parameters.
Kind Regards
Date: Mon, 11 Jul 2011 07:36:52 -0700
From: [hidden email]
To: [hidden email]
Subject: RE: How to get some special metadata of HDF5 Cosmo-Skymed file
To be honest I know nothing about radiation calibration... Did you
checked out this document?
http://www.e-geos.it/products/pdf/COSMO-SkyMed-Image_Calibration.pdf
other relevant information can be found at:
http://www.e-geos.it/products/cosmo.html
Hope it helps!
Regards
2011/7/11 RSyaoxin [hidden email]:
Thanks Antonio Valentino and Alex Mantaut. I've got these
parameters.I have
a new problem,I need to get the backscatter image,but the calibration
result
is not correct,the calibrated image pixels are all zero.I doubt that my
method is not correct.Who can give me some information about Cosmo-Skymed
radiation calibration?How should I do?
Best regards.
Date: Mon, 11 Jul 2011 06:55:54 -0700
From: [hidden email]
To: [hidden email]
Subject: Re: How to get some special metadata of HDF5 Cosmo-Skymed file
Hi RSyaoxin,
Antonio is right, there was an issue on geting the root metadata from
hdf5 files and is has been fixed in trunk, you will need to recompile
gdal in order to get that information.
After you rebuilt the library, an example on getting the metadata:
#include gdal_priv.h
#include iostream
#include cstdlib
#include string
#include stdexcept
using namespace std;
int main(int argc, char **argv)
{
GDALDataset *poDataset;
GDALAllRegister();
//Open the subdataset
//The filename should be formated like this
//HDF5:filepath://subdataset
poDataset = (GDALDataset *) GDALOpen(
HDF5:CSKS1_DGM_B_HR_00_HH_RA_SF_20080211191721_20080211191753.h5://S01/SBI,
GA_ReadOnly );
if( poDataset == NULL )
{
cout error opening datasetendl;
}
else
{
//To get the metadata the item name should be formated like
this:
//Every space and group separator should be replaced with
an underscore (_)
//I.e. You need item Beam ID from group S01:
const char *pszBeamId =
poDataset-GetMetadataItem(S01_Beam_ID);
cout pszBeamId endl;
//I.e. You need item Rescaling factor the root:
const char *pszRescalingFactor =
poDataset-GetMetadataItem(Rescaling_Factor);
cout pszRescalingFactor endl;
}
}
Best regards
2011/7/10 Antonio Valentino [hidden email]:
Hi RSyaoxin,
Il 10/07/2011 16:08, RSyaoxin ha scritto:
Hi,all.
I want to calibrate the Cosmo-Skymed radar data, and I need some
parameters, such as Calibration Constant,Rescaling Factor,Reference
Incidence Angle and so on.However,I'm a beginner,I don't know how to
get
HDF5 metadata,Somebody can give me a tutorial in c or c++?
Furthermore,I used HDFView to see the file's metadata and found
that
these information is stored in the metadata corresponding to the root
of
the file, I try to use gdalinfo to get the file's metadata and can't
find
it.That's why?
Subdatasets:
SUBDATASET_1_NAME=HDF5:D:\CSKS3_GEC_B_WR_01_VV_RD_SF_20100720100133_20100720100148.h5://MBI
SUBDATASET_1_DESC=[9028x12156] //MBI (16-bit unsigned integer)
SUBDATASET_2_NAME=HDF5:D:\CSKS3_GEC_B_WR_01_VV_RD_SF_20100720100133_20100720100148.h5://QLK
SUBDATASET_2_DESC=[902x1215] //QLK (8-bit unsigned character)
I hope to get some help.Thank you!
Kind regards.
The HDF5 driver has been recently updated to improve metadata management:
http://trac.osgeo.org/gdal/changeset/22517
http://trac.osgeo.org/gdal/ticket/2412
The problem you are experimenting should be fixed in trunk but you need
to re-build GDAL from sources to get it.
regards
--
Antonio Valentino
___
gdal-dev mailing list
[hidden email]
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
[hidden email]
www.suremptec.com
___
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
If you reply to this email, your message will be added to the discussion
below:
http://osgeo-org.1803224.n2.nabble.com/How-to-get-some-special-metadata-of-HDF5-Cosmo-Skymed-file-tp6567852p6571000.html
To unsubscribe from How to get some special metadata of HDF5
Re: [gdal-dev] hdf5image metadata problems
Hi, I posted a patch to solve this issue... It fecthes the metadata from the subdaset opened (it keeps the global metadata and it adds the subdaset metadata to it) I tested it and it is working... Please review it to see it isn' disruptive with the rest of the driver's logic. http://trac.osgeo.org/gdal/ticket/4121#comment:4 Regards 2011/6/21 Alex Mantaut alexmant...@suremptec.com.ar: Hi all, I updated the ticket with what was discussed with Antonio... http://trac.osgeo.org/gdal/ticket/4121#comment:3 The defect is still there Regards Alex PS:Sorry for the delay but the weekend was a national holyday... 2011/6/18 Antonio Valentino antonio.valent...@tiscali.it Hi Alex, Il 16/06/2011 17:27, Alex Mantaut ha scritto: Then, to keep consistency, the fact that hdf5imagedataset isn't consistent with the hdf5dataset is a defect, right? May I summarize the conclusions and update the ticket? OK -- Antonio Valentino ___ gdal-dev mailing list gdal-dev@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 alexmant...@suremptec.com.ar www.suremptec.com -- -- Alex Mantaut SUR Emprendimientos Tecnológicos Perú 345 Piso 5to Oficina B (C1067AAG) Ciudad de Buenos Aires, Argentina Tel. +54 (11) 4342-2976/84 alexmant...@suremptec.com.ar www.suremptec.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] HDF5 product handling
Hi Frank, In that case all the handling for the CSK product should go on the Open() method from hdf5imagedataset? Is there any way to avoid polluting the hdf5imagedataset with all the subproduct's constants? Shall I define Product specific private methods as: getCSKGeotransform() to get the information? regards 2011/7/4 Frank Warmerdam warmer...@pobox.com On Mon, Jul 4, 2011 at 8:52 AM, Alex Mantaut alexmant...@suremptec.com.ar wrote: I would like to ask what would be the best way to implement a driver that handles HDF5 subproducts, in a way that it doesn't interfere with the behavior for hdf5 for files that ain't from any specific product type, and allows to add new product types easly... (It's quite likely I will have to add a new hdf5 product type soon) Because hdf5 products are just hdf5 files with a special order in the metadata, I think that the code to interpret them should go in the hdf5dataset (or hdf5imagedataset) to reuse the code that opens the files... Is this okay? If the code for subproducts should go on the hdf5dataset (or hdf5imagedataset) I have a doubt about design... Alex, We have a similar issue in the HDF4 driver. The approach there has roughly been to have one or some data items in the HDF4Dataset class (or perhaps HDF4ImageDataset) which enumerates what the product is, with a generic option for anything which isn't special product. The Open() method has special logic to identify products, and harvest extra metadata depending on the product type. Rather than create subdriver's I'd suggest such using this approach, and perhaps having one 'metadata harvest method on the driver for each subproduct. In many cases that is sufficient. I look forward to seeing your patches! 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 -- -- Alex Mantaut SUR Emprendimientos Tecnológicos Perú 345 Piso 5to Oficina B (C1067AAG) Ciudad de Buenos Aires, Argentina Tel. +54 (11) 4342-2976/84 alexmant...@suremptec.com.ar www.suremptec.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] hdf5image metadata problems
Hi all, I updated the ticket with what was discussed with Antonio... http://trac.osgeo.org/gdal/ticket/4121#comment:3 The defect is still there Regards Alex PS:Sorry for the delay but the weekend was a national holyday... 2011/6/18 Antonio Valentino antonio.valent...@tiscali.it Hi Alex, Il 16/06/2011 17:27, Alex Mantaut ha scritto: Then, to keep consistency, the fact that hdf5imagedataset isn't consistent with the hdf5dataset is a defect, right? May I summarize the conclusions and update the ticket? OK -- Antonio Valentino ___ gdal-dev mailing list gdal-dev@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 alexmant...@suremptec.com.ar www.suremptec.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] hdf5image metadata problems
Hi Antonio, For what I discussed with Frank it seemed that the expected behavior was to get the only the data asociated to that subdataset (plus some aditional data from root and the other groups) I wasn't sure untill you confirmated... Well, right now when I open a specific subdataset it gets only the raster band asociated to that dataset, but when I try to open the metadata (with GetMetadata() or GetMetadataItem()) from that subdataset it opens the metadata from all the groups (as expected) but it doesn't get the metadata asociated to that subdataset... Did I do something incorrectly when opening the metadata from the subdataset? The line suggested in the ticket: ReadGlobalAttributes( TRUE ); Was a way to get around the problem, but now that I'm sure that hdf5imagedataset doesn't need to read all the metadata, it's not a suitable solution to the defect... Right now I found another way to get the metadata from the subdataset, by getting the rasterband first, and then asking for the metadata asociated to that raster band ( it seems a overly convoluted to get the metadata asociated to that subdataset...) I'm guessing that the expected behavior is to get the information directly through GetMetadata() directly... regards 2011/6/15 Antonio Valentino antonio.valent...@tiscali.it Hi Frank, hi Alex, Il 15/06/2011 22:34, Frank Warmerdam ha scritto: On 11-06-15 03:50 PM, Alex Mantaut wrote: Hi Frank: Thanks for the swift reply. Right now it opens the metadata asociated to the root, and also the metadata asociated with all the other groups, but it doesn't open the metadata asociated to the specified element (bug?) Alex, It sounds like a defect to me, yes. I would suggest filing a ticket that carefully documents the problem with a supporting example file. Best regards, The current behavior looks fine to me. If one opens a specific subdataset then only one HDF5 dataset object can be accessed and it is mapped on GDAL raster bans n. 1. All other HDF5 dataset object in the h5 file are ignored by the HDF5ImageDataset so there is no reason IMHO to make their metadata available in some manner. Metadata associated to all HDF5 groups (including the root one) are available in any case and accessible via GDAL dataset metadata. my two cents -- Antonio Valentino ___ gdal-dev mailing list gdal-dev@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 alexmant...@suremptec.com.ar www.suremptec.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] hdf5image metadata problems
Antonio, Ok, I understand the asociation between the raster band and the metadata, but if you have to explicitally ask for the raster band in order to get the metadata there is an inconsistency between the interface to get metadata from hdf5dataset and hdf5imagedataset... In hdf5dataset GetMetadata() returns the metadata asociated to the all the subdatasets without need to explicitally ask for the raster band, but in hdf5imagedataset you have to explicitally ask for the raster band in order to get the metadata... IMHO the interface should be the same in both cases, in that case hdf5imagedataset should retrieve the metadata asociated to the subdataset directly via GetMetadata()... regards PS: Your english is fine, i hope you can understand my lousy english... If you can't explain something in english you can also write in italian to my mail, the we can send a translated message with the conclusions to the list 2011/6/16 Antonio Valentino antonio.valent...@tiscali.it Hi Alex, Il giorno Thu, 16 Jun 2011 10:05:42 -0300 Alex Mantaut alexmant...@suremptec.com.ar ha scritto: Hi Antonio, For what I discussed with Frank it seemed that the expected behavior was to get the only the data asociated to that subdataset (plus some aditional data from root and the other groups) I wasn't sure untill you confirmated... Well, right now when I open a specific subdataset it gets only the raster band asociated to that dataset, but when I try to open the metadata (with GetMetadata() or GetMetadataItem()) from that subdataset it opens the metadata from all the groups (as expected) but it doesn't get the metadata asociated to that subdataset... Did I do something incorrectly when opening the metadata from the subdataset? The line suggested in the ticket: ReadGlobalAttributes( TRUE ); Was a way to get around the problem, but now that I'm sure that hdf5imagedataset doesn't need to read all the metadata, it's not a suitable solution to the defect... Right now I found another way to get the metadata from the subdataset, by getting the rasterband first, and then asking for the metadata asociated to that raster band ( it seems a overly convoluted to get the metadata asociated to that subdataset...) I'm guessing that the expected behavior is to get the information directly through GetMetadata() directly... regards Well, IMHO it is not convoluted. Associating HDF5 dataset metadata tho the GDAL raster band just reflects the original HDF5 structure. Even if HDF5 and GDAL data model are quite different we can assume, IMHO, the following correspondence: HDF5 file-- GDAL dataset (HDF5Dataset class) HDF5 Group -- None (metadata are associated to GDAL dataset) HDF5 Dataset -- GDAL Raster Band HDF5 file can contain several datasets (with arbitrary shape) so the GDAL subdataset mechanism is used to tell to the HDF5ImageDataset class which is the HDF5 dataset the have to be mapped onto the GDAL raster band. I hope this is not too much confusing, with my poor english I'm not able to explain it better :). regards 2011/6/15 Antonio Valentino antonio.valent...@tiscali.it Hi Frank, hi Alex, Il 15/06/2011 22:34, Frank Warmerdam ha scritto: On 11-06-15 03:50 PM, Alex Mantaut wrote: Hi Frank: Thanks for the swift reply. Right now it opens the metadata asociated to the root, and also the metadata asociated with all the other groups, but it doesn't open the metadata asociated to the specified element (bug?) Alex, It sounds like a defect to me, yes. I would suggest filing a ticket that carefully documents the problem with a supporting example file. Best regards, The current behavior looks fine to me. If one opens a specific subdataset then only one HDF5 dataset object can be accessed and it is mapped on GDAL raster bans n. 1. All other HDF5 dataset object in the h5 file are ignored by the HDF5ImageDataset so there is no reason IMHO to make their metadata available in some manner. Metadata associated to all HDF5 groups (including the root one) are available in any case and accessible via GDAL dataset metadata. my two cents -- Antonio Valentino -- Antonio Valentino ___ gdal-dev mailing list gdal-dev@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 alexmant...@suremptec.com.ar www.suremptec.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] hdf5image metadata problems
Then, to keep consistency, the fact that hdf5imagedataset isn't consistent with the hdf5dataset is a defect, right? May I summarize the conclusions and update the ticket? thanks for your patience Antonio 2011/6/16 Antonio Valentino antonio.valent...@tiscali.it Hi Alex, Il giorno Thu, 16 Jun 2011 11:51:48 -0300 Alex Mantaut alexmant...@suremptec.com.ar ha scritto: Antonio, Ok, I understand the asociation between the raster band and the metadata, but if you have to explicitally ask for the raster band in order to get the metadata there is an inconsistency between the interface to get metadata from hdf5dataset and hdf5imagedataset... In hdf5dataset GetMetadata() returns the metadata asociated to the all the subdatasets without need to explicitally ask for the raster band, but in hdf5imagedataset you have to explicitally ask for the raster band in order to get the metadata... IMHO the interface should be the same in both cases, in that case hdf5imagedataset should retrieve the metadata asociated to the subdataset directly via GetMetadata()... Umh, I don't know. I've always considered HDF5Dataset and HDF5ImageDataset as quite different things: the index and the chapters. But I have to admit that yours is a good point. 2011/6/16 Antonio Valentino antonio.valent...@tiscali.it Hi Alex, Il giorno Thu, 16 Jun 2011 10:05:42 -0300 Alex Mantaut alexmant...@suremptec.com.ar ha scritto: Hi Antonio, For what I discussed with Frank it seemed that the expected behavior was to get the only the data asociated to that subdataset (plus some aditional data from root and the other groups) I wasn't sure untill you confirmated... Well, right now when I open a specific subdataset it gets only the raster band asociated to that dataset, but when I try to open the metadata (with GetMetadata() or GetMetadataItem()) from that subdataset it opens the metadata from all the groups (as expected) but it doesn't get the metadata asociated to that subdataset... Did I do something incorrectly when opening the metadata from the subdataset? The line suggested in the ticket: ReadGlobalAttributes( TRUE ); Was a way to get around the problem, but now that I'm sure that hdf5imagedataset doesn't need to read all the metadata, it's not a suitable solution to the defect... Right now I found another way to get the metadata from the subdataset, by getting the rasterband first, and then asking for the metadata asociated to that raster band ( it seems a overly convoluted to get the metadata asociated to that subdataset...) I'm guessing that the expected behavior is to get the information directly through GetMetadata() directly... regards Well, IMHO it is not convoluted. Associating HDF5 dataset metadata tho the GDAL raster band just reflects the original HDF5 structure. Even if HDF5 and GDAL data model are quite different we can assume, IMHO, the following correspondence: HDF5 file-- GDAL dataset (HDF5Dataset class) HDF5 Group -- None (metadata are associated to GDAL dataset) HDF5 Dataset -- GDAL Raster Band HDF5 file can contain several datasets (with arbitrary shape) so the GDAL subdataset mechanism is used to tell to the HDF5ImageDataset class which is the HDF5 dataset the have to be mapped onto the GDAL raster band. I hope this is not too much confusing, with my poor english I'm not able to explain it better :). regards 2011/6/15 Antonio Valentino antonio.valent...@tiscali.it Hi Frank, hi Alex, Il 15/06/2011 22:34, Frank Warmerdam ha scritto: On 11-06-15 03:50 PM, Alex Mantaut wrote: Hi Frank: Thanks for the swift reply. Right now it opens the metadata asociated to the root, and also the metadata asociated with all the other groups, but it doesn't open the metadata asociated to the specified element (bug?) Alex, It sounds like a defect to me, yes. I would suggest filing a ticket that carefully documents the problem with a supporting example file. Best regards, The current behavior looks fine to me. If one opens a specific subdataset then only one HDF5 dataset object can be accessed and it is mapped on GDAL raster bans n. 1. All other HDF5 dataset object in the h5 file are ignored by the HDF5ImageDataset so there is no reason IMHO to make their metadata available in some manner. Metadata associated to all HDF5 groups (including the root one) are available in any case and accessible via GDAL dataset metadata. my two cents -- Antonio Valentino ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http
[gdal-dev] hdf5image metadata problems
Hi all, I'm trying to open the metadata from a subdataset of an HDF5 file... When I open the file by it's filename and then ask for the metadata it returns the metadata asociated to the root and all the subdatasets But when I open the file by specifying the subdataset name to GDALOpen() and then ask for the metadata it returns the metadata asociated to all groups but none of the subdatasets... I looked a bit into the hdf5dataset code and realized that this difference emerges from the fact that when GDAL opens the file specifying only the filename it uses hdf5dataset to open the file, but when I specify the subdataset to GDALOpen() it uses hdf5imagedataset instead, and it loads the metadata in a different way. I'm not sure of what the expected behavior is on hdf5image for loading metadata... It should load all the metadata of the file? Just the metadata asociated to the subdataset? Or should the application ask for the subdataset in some other way and then ask for the metadata? gdalinfo is returning the metadata asociated to the subdataset in both cases, but it shows the data in the bands section... So I looked in to the code of gdalinfo and it gets the information for the subdataset like this: GDALRasterBandH hBand; hBand = GDALGetRasterBand( poDataset, 1); char **allMetadata = GDALGetMetadata( hBand, NULL ); Must I use that in order to get the metadata? Thanks in advance -- -- Alex Mantaut SUR Emprendimientos Tecnológicos Perú 345 Piso 5to Oficina B (C1067AAG) Ciudad de Buenos Aires, Argentina Tel. +54 (11) 4342-2976/84 alexmant...@suremptec.com.ar www.suremptec.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] hdf5image metadata problems
Hi Frank: Thanks for the swift reply. Right now it opens the metadata asociated to the root, and also the metadata asociated with all the other groups, but it doesn't open the metadata asociated to the specified element (bug?) regards 2011/6/15 Frank Warmerdam warmer...@pobox.com On 11-06-15 03:19 PM, Alex Mantaut wrote: Hi all, I'm trying to open the metadata from a subdataset of an HDF5 file... When I open the file by it's filename and then ask for the metadata it returns the metadata asociated to the root and all the subdatasets But when I open the file by specifying the subdataset name to GDALOpen() and then ask for the metadata it returns the metadata asociated to all groups but none of the subdatasets... I looked a bit into the hdf5dataset code and realized that this difference emerges from the fact that when GDAL opens the file specifying only the filename it uses hdf5dataset to open the file, but when I specify the subdataset to GDALOpen() it uses hdf5imagedataset instead, and it loads the metadata in a different way. I'm not sure of what the expected behavior is on hdf5image for loading metadata... It should load all the metadata of the file? Just the metadata asociated to the subdataset? Or should the application ask for the subdataset in some other way and then ask for the metadata? Alex, I'm not sure of the details of the metadata handling, but to the extent possible I think opening a subdataset should return metadata specific to that subdataset and any root metadata that applies to everything in the .hdf file. 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 -- -- Alex Mantaut SUR Emprendimientos Tecnológicos Perú 345 Piso 5to Oficina B (C1067AAG) Ciudad de Buenos Aires, Argentina Tel. +54 (11) 4342-2976/84 javierur...@suremptec.com.ar www.suremptec.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] hdf5image metadata problems
Frank: I opened a new defect ticket, and suggested a way around the problem (I'm not sure if it's the best solution) http://trac.osgeo.org/gdal/ticket/4121 Regards 2011/6/15 Frank Warmerdam warmer...@pobox.com On 11-06-15 03:50 PM, Alex Mantaut wrote: Hi Frank: Thanks for the swift reply. Right now it opens the metadata asociated to the root, and also the metadata asociated with all the other groups, but it doesn't open the metadata asociated to the specified element (bug?) Alex, It sounds like a defect to me, yes. I would suggest filing a ticket that carefully documents the problem with a supporting example file. 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 -- -- Alex Mantaut SUR Emprendimientos Tecnológicos Perú 345 Piso 5to Oficina B (C1067AAG) Ciudad de Buenos Aires, Argentina Tel. +54 (11) 4342-2976/84 alexmant...@suremptec.com.ar www.suremptec.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] HDF5 metadata format problems
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 warmer...@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, 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 -- -- Alex Mantaut SUR Emprendimientos Tecnológicos Perú 345 Piso 5to Oficina B (C1067AAG) Ciudad de Buenos Aires, Argentina Tel. +54 (11) 4342-2976/84 javierur...@suremptec.com.ar www.suremptec.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] HDF5 metadata format problems
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... 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? 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? Sorry for the long mail Thanks in advance -- -- Alex Mantaut SUR Emprendimientos Tecnológicos Perú 345 Piso 5to Oficina B (C1067AAG) Ciudad de Buenos Aires, Argentina Tel. +54 (11) 4342-2976/84 javierur...@suremptec.com.ar www.suremptec.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] HDF5 COSMO-SKYMED metadata problems
I tried the patch warmerdam posted on the 1.8.0 version an it worked, i can see the root metadata now. Thanks Antonio Valentino and Frank Warmerdam for the swift correction. Another issue. Does anybody has the COSMO-SKYMED HDF5 2011/6/7 Alex Mantaut alexmant...@suremptec.com.ar Antonio: Thanks for the swift answer. I've tried to apply the patch to gdal 1.8 but it fails on the 5º chunk (hdf5dataset.cpp from line 598) I looked at the code and it seems significantly diffrent (perhaps this class was modified since the patch was released a year ago?) Can you release a newer version of the patch please? Vi ringrazio un'altra volta 2011/6/7 Antonio Valentino antonio.valent...@tiscali.it Hi Alex, Il 07/06/2011 20:13, Alex Mantaut ha scritto: Hi: I'm trying to get georreference information from an HDF5 COSMO-SKYMED file. I used HDFView to see the file's metadata and found that in this type of HDF5 files the georreference information is stored in the metadata corresponding to the root of the file. The problem is that when i try to use gdalinfo to get the file's metadata, it shows the metadata asociated to all the subdatasets included on the file, but not the root's metadata... My cuestions: How do i get the metadata asociated to the root of the file? Is there a better way to get georreference from COSMO-SKYMED HDF5 files? Thanks in advance Ticket #2412 [1] has an associated patch that could be useful in your case (i.e for retrieving metadata associated to the root group). [1] http://trac.osgeo.org/gdal/ticket/2412 ciao -- Antonio Valentino ___ gdal-dev mailing list gdal-dev@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 javierur...@suremptec.com.ar www.suremptec.com -- -- Alex Mantaut SUR Emprendimientos Tecnológicos Perú 345 Piso 5to Oficina B (C1067AAG) Ciudad de Buenos Aires, Argentina Tel. +54 (11) 4342-2976/84 javierur...@suremptec.com.ar www.suremptec.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] HDF5 COSMO-SKYMED metadata problems
Sorry, I accidentalñy pressed the send button Another issue. Does anybody has the COSMO-SKYMED HDF5 format specification or something that tells how to get the georreference information from those files? 2011/6/8 Alex Mantaut alexmant...@suremptec.com.ar I tried the patch warmerdam posted on the 1.8.0 version an it worked, i can see the root metadata now. Thanks Antonio Valentino and Frank Warmerdam for the swift correction. Another issue. Does anybody has the COSMO-SKYMED HDF5 2011/6/7 Alex Mantaut alexmant...@suremptec.com.ar Antonio: Thanks for the swift answer. I've tried to apply the patch to gdal 1.8 but it fails on the 5º chunk (hdf5dataset.cpp from line 598) I looked at the code and it seems significantly diffrent (perhaps this class was modified since the patch was released a year ago?) Can you release a newer version of the patch please? Vi ringrazio un'altra volta 2011/6/7 Antonio Valentino antonio.valent...@tiscali.it Hi Alex, Il 07/06/2011 20:13, Alex Mantaut ha scritto: Hi: I'm trying to get georreference information from an HDF5 COSMO-SKYMED file. I used HDFView to see the file's metadata and found that in this type of HDF5 files the georreference information is stored in the metadata corresponding to the root of the file. The problem is that when i try to use gdalinfo to get the file's metadata, it shows the metadata asociated to all the subdatasets included on the file, but not the root's metadata... My cuestions: How do i get the metadata asociated to the root of the file? Is there a better way to get georreference from COSMO-SKYMED HDF5 files? Thanks in advance Ticket #2412 [1] has an associated patch that could be useful in your case (i.e for retrieving metadata associated to the root group). [1] http://trac.osgeo.org/gdal/ticket/2412 ciao -- Antonio Valentino ___ gdal-dev mailing list gdal-dev@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 javierur...@suremptec.com.ar www.suremptec.com -- -- Alex Mantaut SUR Emprendimientos Tecnológicos Perú 345 Piso 5to Oficina B (C1067AAG) Ciudad de Buenos Aires, Argentina Tel. +54 (11) 4342-2976/84 javierur...@suremptec.com.ar www.suremptec.com -- -- Alex Mantaut SUR Emprendimientos Tecnológicos Perú 345 Piso 5to Oficina B (C1067AAG) Ciudad de Buenos Aires, Argentina Tel. +54 (11) 4342-2976/84 javierur...@suremptec.com.ar www.suremptec.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] HDF5 COSMO-SKYMED metadata problems
Hi: I'm trying to get georreference information from an HDF5 COSMO-SKYMED file. I used HDFView to see the file's metadata and found that in this type of HDF5 files the georreference information is stored in the metadata corresponding to the root of the file. The problem is that when i try to use gdalinfo to get the file's metadata, it shows the metadata asociated to all the subdatasets included on the file, but not the root's metadata... My cuestions: How do i get the metadata asociated to the root of the file? Is there a better way to get georreference from COSMO-SKYMED HDF5 files? Thanks in advance -- -- Alex Mantaut SUR Emprendimientos Tecnológicos Perú 345 Piso 5to Oficina B (C1067AAG) Ciudad de Buenos Aires, Argentina Tel. +54 (11) 4342-2976/84 javierur...@suremptec.com.ar www.suremptec.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] HDF5 COSMO-SKYMED metadata problems
Antonio: Thanks for the swift answer. I've tried to apply the patch to gdal 1.8 but it fails on the 5º chunk (hdf5dataset.cpp from line 598) I looked at the code and it seems significantly diffrent (perhaps this class was modified since the patch was released a year ago?) Can you release a newer version of the patch please? Vi ringrazio un'altra volta 2011/6/7 Antonio Valentino antonio.valent...@tiscali.it Hi Alex, Il 07/06/2011 20:13, Alex Mantaut ha scritto: Hi: I'm trying to get georreference information from an HDF5 COSMO-SKYMED file. I used HDFView to see the file's metadata and found that in this type of HDF5 files the georreference information is stored in the metadata corresponding to the root of the file. The problem is that when i try to use gdalinfo to get the file's metadata, it shows the metadata asociated to all the subdatasets included on the file, but not the root's metadata... My cuestions: How do i get the metadata asociated to the root of the file? Is there a better way to get georreference from COSMO-SKYMED HDF5 files? Thanks in advance Ticket #2412 [1] has an associated patch that could be useful in your case (i.e for retrieving metadata associated to the root group). [1] http://trac.osgeo.org/gdal/ticket/2412 ciao -- Antonio Valentino ___ gdal-dev mailing list gdal-dev@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 javierur...@suremptec.com.ar www.suremptec.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
