OPeNDAP HDF4 Handler Limitations
This new enhanced handler has many limitations. Not all HDF/HDF-EOS2 products can be visualized by the OPeNDAP clients using this handler. Here, we summarize why some products cannot be visualized and list some data products and sample files that fail to be accessed by OPeNDAP visualization clients at the end of this page.
Reasons of Visualization Failure
1. No Support for Multiple Geo-location information
Most visualization clients expect the shared geo-location information datasets (a.k.a shared dimensions or map data) among DAP Grids and Swath following CF convention. Thus, if an HDF-EOS2 file has multiple geo-location information with different arrays sizes, the enhanced handler will throw an error saying The HDF-EOS2 library cannot process this file.2. No Support for Vgroups
The enhanced handler suppresses the handling of Vgroups for the technical reasons of the old HDF4 handler. Thus, if the same dataset name (including dimension information like Latitude/Longitude) is used under the two different Vgroups, the handler throws an error "Problem with DDS semantics" to avoid ambiguity. CERES files will show this error message.3. No Support for Duplicate Name
Generating all shared dimensions could result in the DDS semantics problem. For example, some MODIS Grid files used the same name for both Grid variable and geo-location information variable. When a shared dimension variable x is generated outside a Grid variable x[x=3][lat=180][lon=360], the OPeNDAP library detects the x as a duplicate variable name in DDS. In this case, the HDF4 handler throws an error "Problem with DDS semantics" to avoid ambiguity. One work-around solution for this problem is to disable all dds.check_semantics() in hdfdesc.cc source code since some OPeNDAP visualization clients like IDV and Panoply do not care whether using the same name for Grid variable and dimension variable. However, the GrADS will complain with an error message Grid map variable `x' conflicts with the grid array name in grid `x'.
Figure 1: Panoply works on MODIS Grid if dds.check_semantics() is disabled.
4. No Support for Some Projection
Some 2-D Grid projection like Lamaz projection cannot be supported.5. No Support for Point data
No Point data can be visualized.6. No Support for Swath with 1-D geo-location Data
Some HDF-EOS Swath files use 1-D geo-location data array. This is rather unusual because mose Swath files have 2-D geo-location data array and it is more like a time series data on a (lat, lon) point. The DDS structure looks like below:7. No Support for Invalid Character
There's a bug in the OPeNDAP system that returns a garbage character if '%' is used as an HDF-EOS object name. For example, IDV will throw an error saying Illegal Netcdf Object Name = 'Valid_EV_Obs_Band_2_(some garbage character...', should be [a-zA-Z_][a-zA-Z0-9_@:\.\-\(\)\+]* when it reads such object.List of Sample Unsupported Data
Here's a sample list of unsupported HDF-EOS2 data that fail to display using clients.
| Mission | Instrument | Type | Sample Filename | Reason for Failure |
| AQUA | MODIS | Swath | MAC05S0.A2006153.0000.002.2007098162108.hdf | 1 |
| TERRA | MISR | Grid | MISR_LAND_FIRSTLOOK_P068_O044103_F07_0022_ATS_b32-38.hdf | 1 |
| TERRA | MODIS | Swath | AST_L1B_00305292006080906_20060604094034_7323.hdf | 2 |
| AQUA | MODIS | Grid | MOD08_D3.A2008284.005.2008289105354.hdf | 3 |
| TERRA | MISR | Grid | MISR_AM1_CGAS_MAR_01_2006_SITE_INTEXB_F06_0021.hdf | 4 |
| AQUA | AMSR-E | Point | AMSR_E_L2_Land_B04_200206182340_A.hdf | 5 |
| TERRA | MOPITT | Swath | MOP02-20000303-L2V5.7.1.val.hdf | 6 |
| AQUA | MODIS | Swath | MOD10_L2.A2000136.0235.004.2003009030119.hdf | 7 |
- - Last modified:September 23rd 2009