Space Bin Modifications for OCTS

The Level 3 ocean products generated by SeaWiFS and SIMBIOS follow a convention known as the "dataday". The dataday is defined geographically, according to the time when the spacecraft orbit crosses the 180 degree meridian (hereafter called the date line) closest to the equator. A detailed explanation of the dataday can be found in the SeaWiFS Prelaunch Technical Report Series, volume 27, chapter 5.

In order to apply the dataday convention, the Level 2-to-3 binning program splits any Level 2 files which cross the date line into two Level 3 files. The pixels which are west of the date line are assigned to a dataday one later than those east of the line. The determination of the appropriate dataday involves two separate steps. A program is run to determine the start and end times of the current dataday, using the GMT day of the file as a starting point. Then, the binning program (called spacebin) determines whether each pixel should be associated with the current, previous, or following dataday, based on the observation time and location.

During the testing of this processing for the OCTS GAC data, two problems were found; they are described, along with their solutions, below.

1. The file time was outside the range of the primary dataday.

   The OCTS orbit has an equator crossing time of 10:30 AM, compared to 12 noon for SeaWiFS. As a result, the date line crossings occur, on average, about 90 minutes before midnight UTC, as do the dataday start and end times. It was found that files which had times between the dataday end time and midnight UTC were not being binned properly. The problem was that the primary dataday was being assigned based on the UTC day for the file, regardless of whether the file time fell within the actual time range for the dataday.

   The solution is to perform an additional check to ensure that the file time falls within the primary dataday time range. If not, the dataday is either incremented (if the data time is after the dataday) or decremented (if before), and the dataday start and end time are recomputed.

2. Files near the middle of the dataday had alternate datadays assigned incorrectly.

   At the time of spacebin execution, each file has been assigned a primary dataday, as described in the previous item. The program then assigns either the previous or following dataday as an alternate, to be used if the file crosses the date line. This assignment is performed using the file time and the dataday start and end time. If the file time falls within the first half of the dataday, the previous day is selected as the alternate; otherwise the following day is selected.

   During the test runs it was found that in the winter months, many files near the dataday midpoint (i.e., 10:30 UTC) were not being binned. Two problems were identified which contributed to this problem:

   1. The selection of the alternate dataday was being performed using the file start time, which biased the selection toward the previous day.
   2. The selection was being performed by first checking if the file time was within 12 hours of the dataday start time. The dataday start and end times are not exactly 24 hours apart, because there is not an integral number of orbits per day. For datadays less than 24 hours long, this logic also biased the selection toward the previous day.

   This caused problems in the winter months due two factors. The low solar declination caused the data collection to extend well past the South pole, which significantly increased the longitudinal coverage. In addition, due to the eliminination of sensor tilting in December 1996, each file spanned the entire daylight part of the orbit. As a result, many files collected near 10:30 UTC extended from the Greenwich meridian past the date line. The incorrect selection of the previous dataday as the alternate for these files resulted in no data being binned.

   The solution is twofold: first, the file mid-time is used for this selection, rather than the start time; and second, the selection is performed using the actual midpoint of the dataday, rather than 12 hours from the start time.

   It should be noted that these problems have almost certainly affected SeaWiFS data processing as well. However, the data collection for SeaWiFS spans slightly less than the full orbit day. As a result, the longitudinal coverage of the winter files is smaller, and the problem manifests itself less frequently.