![]() |
MISR Reformatted Products Quality Statement |
This statement applies to any gridded MISR Level-1 and Level-2 product that is post-processed via the MISR Data Subsetting Interface at NASA Langley Atmospheric Science Data Center. These include the following products:
Subsetted / reformatted products are derived from MISR Level 1 and Level 2 Standard Products. Therefore, the product maturity designations and quality statements of the parent products are applicable to the subsetted / reformatted products. However, some of the transformations executed by this tool may affect data content as described on this page.
The MISR Data Subsetting Interface was originally developed to provide a means of subsetting MISR products to reduce data volumes delivered to users. In addition to subsetting, the interface also supports reformatting options which are intended to make MISR products easier to use. The interface currently supports three output formats: 1) HDF-EOS swath, 2) stacked-block HDF-EOS grid, and 3) conventional HDF-EOS grid. The HDF-EOS swath format is used by Level-1A (MIL1A) and Level-1B1 (MI1B1) products only, which are not discussed in this document. Stacked-block HDF-EOS is the native format used for the gridded MISR Level-1 and Level-2 products. Conventional HDF-EOS is designed to be an easier-to-use alternative to stacked-block grid format.
Stacked-block HDF-EOS format is a MISR specific extension to the HDF-EOS library that is only used by MISR and is not widely supported by third party data analysis tools. Tools which support HDF-EOS or HDF can usually import stacked-block data to a limited extent, but users quickly run into problems. Two problems commonly encountered are: 1) piecing together the MISR blocks, so they are aligned correctly with respect to each other; and 2) geolocating the MISR data in a map context. Many tools do not support geolocation of the stacked-block HDF-EOS format.
Some JPL/MISR provided tools, which fully support stacked-block format include, misr_view, hdfscan, hdfdump and brfdump. The HDF-EOS to GeoTIFF (HEG) tool, provided by EOSDIS, also supports stacked-block format. Additional information about these tools, including where to download them, is available from the "Tools" section of the MISR Data Access Table.
A detailed discussion of the stacked-block HDF-EOS format including instructions on how to write software to geolocate MISR data are discussed in Appendix A of the Data Products Specifications Document available from the MISR Data Access Table.
There are no known quality problems introduced by the MISR Data Subsetting Interface when the output format is stacked-block HDF-EOS.
The conventional HDF-EOS format is an alternative format that uses only common HDF-EOS elements, specifically excluding use of the stacked-block extensions. As a result, the conventional HDF-EOS format should be easily imported into any tools that support generic HDF-EOS. In practice however, there are still many tools which have only limited support for HDF-EOS. So this format is not expected to solve all data access difficulties, it is merely an alternative to the stacked-block format, which some users may find easier to work with.
Conventional HDF-EOS format attempts to reproduce the data content of the archived products, only changing the data format. However, there are some notable differences in the data content for some fields which are discussed in detail below. Geolocation is based on the standard parameters used by the General Cartographic Transformation Package (GCTP) library which is distributed with the HDF-EOS library. Data is map projected using the same Space Oblique Mercator (SOM) projection as the archived products.
| Most fields are gridded identically to the archived products and are therefore identical in content to the archived products. The exception occurs for data at resolutions of 35.2 km and 70.4 km in the Level-2 Aerosol/Surface (L2AS) Products and Level-2 Top-of-Atmosphere/Cloud (L2TC) Products. The root of this problem lay within the stacked-block format, which allows the MISR block locations to be offset with respect to each other by multiples of 17.6 km. At pixel resolutions larger than 17.6 km, the block offset is a fraction of a pixel. Therefore, the MISR data is actually computed over an irregular grid, in which the pixels are not lined up in regular columns, but instead are shifted by fractions of their size as illustrated in Figure 1 (PDF format). [A Portable Document Format (PDF) reader (such as Adobe Acrobat Reader) is required to open and view PDF documents.] | Figure 1 |
|---|---|
![]() |
This problem affects the following parameters:
Data for all parameters listed above is shifted by up to one-half a pixel, to align with the nearest pixel in the conventional HDF-EOS grid. All the data numbers, however, remain the same as those in the archived products. The effect is a geolocation error of up to 17.6 km for 35.2 km resolution parameters; and up to 35.2 km for 70.4 km resolution parameters. To account for this error, "Latitude" and "Longitude" fields are provided which give the original location of each pixel prior to shifting.
This means there will be two sources of geolocation information for the above parameters. First is the implicit geolocation of each pixel as defined by the GCTP map projection information. This implicit geolocation information will have an error of up to one-half a pixel. The second source of geolocation is the "Latitude" and "Longitude" fields which explicitly specify the lat/lon location for the center of each pixel. The "Latitude" and "Longitude" fields will always have the correct geolocation information. By comparing the implicit lat/lon against the explicit lat/lon, one can determine which pixels have been shifted, and by how much.
The 1.1 km resolution "LandHDRF" and "LandBRF" fields in the L2AS Land Surface (a.k.a. AS_LAND, MIL2ASLS) product have been split into separate fields by band. This is necessary due to an HDF4 dataset size limitation. The new field names are:
"Latitude" and "Longitude" layers have been added to some grids to explicitly define the latitude and longitude of each pixel. This is done for two reasons. First, is to report the original location of pixels that have been shifted (see Geolocation Issues above). Second, is to provide an alternate source of geolocation information, which may be used to verify that a third party tool is calculating latitude/longitude correctly from the provided map projection information. For example, most tools which support map projected data are able to calculate and display lat/lon values for any pixel. To verify that the calculated values are correct, one can compare the calculated value to the lat/lon explicitly stored for each pixel in the "Latitude" and "Longitude" fields.
To avoid adding significantly to the data volume, "Latitude" and "Longitude" fields are only added to grids with resolution 17.6 km or larger.
For each grid, a "Block_number" field is added, which gives the MISR block number for each pixel. MISR block numbers are 1-based, with a range of 1 to 180. Block number 0 is used for pixels outside the bounds of the MISR swath. For more information about MISR blocks, see Appendix A of the Data Products Specifications Document, available from the MISR Data Access Table.
The JPL/MISR provided tools mentioned above, which are designed to support stacked-block format, do not currently support the conventional HDF-EOS format. Specifically, the following tools do not support conventional HDF-EOS format: misr_view, hdfscan, hdfdump and brfdump. One exception is that hdfscan is able to display all the meta-data components of a conventional HDF-EOS format file; but it does not display the gridded data.
ENVI version 4.0 (a product of ITT Visual Information Solutions), can successfully import and display most data fields in a conventional HDF-EOS format file. ENVI does not automatically import HDF-EOS geolocation parameters, but this information can be entered manually by the user, using provided ENVI instructions. ENVI does not support import of HDF fields with more than three dimensions, including the X, Y, spatial dimensions. Therefore, MISR parameters including both camera and band dimensions cannot be displayed in ENVI.
Other tools supporting HDF-EOS can be found at the HDF-EOS Tools and Information Center.
If you have suggestions for other capabilities you would like to see, please submit your feedback to NASA Langley ASDC User Services.