What happens if HDF-EOS2 grid data has wrong parameters

This page is about an error that may happen when a grid object contains invalid data. Users may want to retrieve longitude and latitude values from a grid object, and one handy way is to use an HDF-EOS2 API, GDij2ll. We noticed that this function failed for several data products, and this page explains the reason.

Using GDij2ll requires some background knowledge. It takes several parameters, and many of them can be retrieved by calling other HDF-EOS2 APIs. This page will not explain these steps as they are described in How to Read Longitude and Latitude Values from HDF-EOS2 Grid Data in C.

Projection Parameter Array

Among many parameters GDij2ll takes, there is a parameter called projection parameter array, which can be retrieved by calling GDprojinfo. This array provides various parameters related to projection, and the usage of these parameters varies depending on the projection method.

When the Lambert Azimuthal Equal Area projection is used, one of elements of that array specifies center longitude. We noticed that some files have an invalid value for this element, and this causes GDij2ll to raise an error. For example, one file from MISR Level 3 Component Global Aerosol Regional public Product covering a day V002 dataset was the case. You can download one sample file from here. In this file, center longitude was -92970000, which is interpreted as the following:

• -92 degrees
• 970 minutes
• 000.00 seconds

Obviously, the minute value is not in the valid range. A C program that tries to access the above file can be found here.

One way to avoid this problem is to correct the value. Calculating the correct value may require expert knowledge. Also, changing the value is not conveniently done.

Corners

Among many parameters GDij2ll takes, there are two important parameters called Location of upper left corner of the upper left pixel(upleft), and Location of lower right corner of the lower right pixel(lowright). They can be retrieved by calling GDgridinfo.

For those two parameters, the HDF-EOS2 Reference states the following:

However, we could see some data products that do have follow packed degree format even though they use the Geographic projection.

For example, one file of AIRS/Aqua Level 3 monthly quantization in physical units (AIRS+AMSU+HSB)(AIRH3QPM) GES-DISC has suspicious values. You can download one file from here. The values of upleft and lowright in this file are [0, 35] and [71, 0]. Given that the Geographic projection is used, these values mean that the range of longitude is 0 ~ 71 seconds, and the range of latitude is 35 seconds ~ 0. This range is suspiciously tiny.

Another example is a file of Nadir BRDF- Adjusted Reflectance(MCD43C4) from MODIS. You can download one sample file from here. The values of upleft and lowright are [-180, 90] and [180, -90], and its projection method was the Geographic projection. These values do not mean the ranges are from 180'W to 180'E and from 90'N to 90'S. They indicate that the coverage is smaller than 1 degree, which is suspiciously tiny.

We guess the format of those values is not packed degree format. If we use those values as they are, GDij2ll returns very small (almost 0) longitude and latitude values for any location. You can try those files with two simple C programs: AIRH3QPM, and MCD43C4. One way to avoid this problem is to adjust upleft and lowright before calling GDij2ll if one knows those values are not correct.

Last modified: 11/11/2020