n the conversion from stacked-block to conventional format, data is reprojected onto a flat 2-dimensional grid, so that the MISR blocks can be aligned appropriately with respect to each other. For most fields this reprojection is trivial, requiring no resampling; i.e. the reprojected data is identical in content to the original stacked-block format.
This problem affects the following parameters:
Product, Grid, Resolution
- Level 2 TOA/Cloud Albedo (MIL2TCAL), AlbedoParameters_35.2_km, 35.2 km
- Level 2 TOA/Cloud Stereo (MIL2TCST), DomainParams, 70.4 km
- Level 2 TOA/Cloud Classifiers (MIL2TCCL), CloudClassifiers_35.2_km, 35.2 km
- Level 2 Land Surface (MIL2ASLS), DomParamsAer, 70.4 km
The exception occurs for data at resolutions of 35.2 km and 70.4 km. 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 shown in the illustration of geolocation error
Data for all parameters listed above are 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 original 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. Second 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.