[Gdal-dev] LANDSAT 7 ETM+ HDF file

[Ivan Lucena]

Inessa,

 

The USGS Landsat Project at
http://landsat.usgs.gov/data_products/sample_products.php names some of
Landsat image products as HDF, like:

 

Enhanced Thematic Mapper Plus (ETM+) Data Products:

 

Product

Format

Download

Level 0Rp

HDF

 ftp <ftp://edclpdsftp.cr.usgs.gov/SAMPLE/DATA/slc_on/single/L0Rp>  |
gzip
<ftp://edclpdsftp.cr.usgs.gov/SAMPLE/DATA/files/on_single_L0Rp.tar.gz>
(295.81 MB)

Level 1R

HDF

 ftp <ftp://edclpdsftp.cr.usgs.gov/SAMPLE/DATA/slc_on/single/L1R>  |
gzip
<ftp://edclpdsftp.cr.usgs.gov/SAMPLE/DATA/files/on_single_L1R.tar.gz>
(368.08 MB)

Level 1G

HDF

 ftp <ftp://edclpdsftp.cr.usgs.gov/SAMPLE/DATA/slc_on/single/L1G_HDF>  |
gzip
<ftp://edclpdsftp.cr.usgs.gov/SAMPLE/DATA/files/on_single_L1G_HDF.tar.gz
>  (271.36 MB)

 

GeoTiff

 ftp <ftp://edclpdsftp.cr.usgs.gov/SAMPLE/DATA/slc_on/single/L1G_tif>  |
gzip
<ftp://edclpdsftp.cr.usgs.gov/SAMPLE/DATA/files/on_single_L1G_tif.tar.gz
>  (271.52 MB)

 

Fast-L7A

 ftp <ftp://edclpdsftp.cr.usgs.gov/SAMPLE/DATA/slc_on/single/L1G_fast>
|  gzip
<ftp://edclpdsftp.cr.usgs.gov/SAMPLE/DATA/files/on_single_L1G_fast.tar.g
z> (133.58 MB)

 

NDF

 ftp <ftp://edclpdsftp.cr.usgs.gov/SAMPLE/DATA/slc_on/single/L1G_NDF>  |
gzip
<ftp://edclpdsftp.cr.usgs.gov/SAMPLE/DATA/files/on_single_L1G_NDF.tar.gz
>  (261.52 MB)

 

But that is just an identity mistake. In this case HDF means
Hierarchical Data Format, but the internal binary data structure is not
the same as in a HDF-EOS version 4 or 5, that GDAL supports.

 

If you download one o those "HDF" above you end up with a bunch of files
with names like: 

 

L71039037_03720030325_B10.L1R

L71039037_03720030325_B20.L1R

L71039037_03720030325_B30.L1R

L71039037_03720030325_B40.L1R

L71039037_03720030325_B50.L1R

L71039037_03720030325_B61.L1R

L71039037_03720030325_CAL.L1R

L71039037_03720030325_GEO.L1R

L71039037_03720030325_HDF.L1R

L71039037_03720030325_MSD.L1R

L71039037_03720030325_MTA.L1R

L71039037_03720030325_MTL.L1R

L71039037_03720030325_PCD.L1R

L71039037_03720030325_SLO.L1R

L72039037_03720030325_B62.L1R

L72039037_03720030325_B70.L1R

L72039037_03720030325_B80.L1R

L72039037_03720030325_CAL.L1R

L72039037_03720030325_MTA.L1R

L72039037_03720030325_SLO.L1R

L72039037_03720030917_B62.L1R

L72039037_03720030917_B70.L1R

L72039037_03720030917_B80.L1R

L72039037_03720030917_CAL.L1R

 

You can read those files in a commercial GIS like Idrisi or Envi or in a
free GIS like Spring or Grass. All of then have an old but good Landsat
import functionality that in most of the cases will ask the user which
format of Landsat are they talking about, HDF, NDF, GeoTiff... I calling
it old because they precede the existence of HDF-EOS 4 satellite images,
like those from Modis, Aqua or Aster.

 

But to make matter worst, the individual file
L71039037_03720030325_HDF.L1R in this example is a truly HDF! But it's
used just as a header file, as a directory of the real thing that comes
in the bands files (_B10.LR1, _B20,LR2). GDAL's gdalinfo can read the
sub-dataset list from that "HDF" but that is all. By the way, the
metadata is on _MTA.L1R, but it doesn't seams useful.

 

So I agree with Andrey's advice that you should get a GeoTiff version of
that data and GDAL will handle it.

 

CASE CLOSED, I guess.

 

But for a GDAL development perspective, I don't think is worth to
investigate it, but I think that once you call the hdf and hdf-eos
libraries you probably should be able to ask for the data anyway even if
it's in another companion file. As an experiment, I tried to open the
file L71039037_03720030325_HDF.L1R as an HDF-EOS in Idrisi and import
some of the bands, and it work. And I know that the code is just calling
the NCSA/NASA library to get the data. The same think happens with
HDFExplorer, I can confirm with Pedro, because I don't have access to
his code. What I am saying is that it could be a bug in the HDF4 driver.
BTW the html for HDF5 is replicating the HDF4 address.

 

Ivan Lucena

 

________________________________

From: gdal-dev-bounces at lists.maptools.org
[mailto:gdal-dev-bounces at lists.maptools.org] On Behalf Of Inessa
Shalomov
Sent: 18 July 2006 15:20
To: Gdal-dev at lists.maptools.org
Subject: [Gdal-dev] LANDSAT 7 ETM+ HDF file

 

Hello Everyone,

 

Thank you so much for all the help and answers. As a result of the
couple forum discussions, I am beginning to question the following:

 

Does GDAL HDF support LANDSAT 7 ETM+ HDF file formats? 

 

Thanks,

Inessa

  

________________________________

Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail Beta.
<http://us.rd.yahoo.com/evt=42297/*http:/advision.webevents.yahoo.com/ha
ndraisers> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20060719/100c988a/attachment.html