Technical Support Document for U.S. EPA’s Proposed Rule for Numeric Nutrient Criteria, Volume 2 Coastal Waters
Appendix A. 

# Appendix B : Supporting Documentation f

or Remote Sensing Methods

November 30 , 2012Technical Support Document for U.S. EPA’s Proposed Rule for Numeric Nutrient Criteria, Volume 2 Coastal Waters



### B

- ii 

## Contents 1. SeaDAS Training Manual 2. SeaWiFS Level -1A Data Products 3. Ocean Discipline Processing System (ODPS) Land/Water Mask Format 4. Ocean Level -2 Data Products 5. Ocean Level
- 3 Binned Data Products

# SeaDAS Training Manual

Ocean Biology Processing Group October 29, 20072

# Chapter 1 

# An Introduction to the OBPG

Introduction This chapter introduces the NASA Ocean Biology Processing Group (OBPG) and the software used in conjunction with data distributed by the group, the SeaWiFS Data Analysis System (SeaDAS). 

## 1.1 What is the OBPG? The goal of the Ocean Biology Processing Group is to make available the highest quality ocean color and SST data to the broadest user community in the most timely and efficient manner possible. More specifically the OBGP is the:

• Designated NASA team responsible for the processing and distribution of ocean color and SST data from various spaceborne instruments: – Ocean Color : MODIS/Aqua, MODIS/Terra, SeaWiFS, OCTS, CZCS – SST : MODIS/Aqua, MODIS/Terra

• Product Evaluation and Test Element (PEATE) for OC and SST on NPP/VIIRS

• Science Team Lead for OC on NPP/VIIRS.

• Designated as the software development, processing, and distribution element for Sea Surface Salinity measurements from Aquarius. 

## 1.2 What Services does the OBPG Provide? The primary service provided by the OBPG is data distribution, the details of which are covered in the next chapter. Main features of the data distribution system are:

• Instant access : entire archive of Level-1A through Level-3 data for all missions is stored online

• Minimal latency : MODIS L0/L1A/GEO/L1B/L2 data available 2-5 hours after satellite observation

• Web-based browser : simple viewing/order/download tool for the entire multi-mission data set

• Full ftp access : data may be downloaded via ftp 34 CHAPTER 1. AN INTRODUCTION TO THE OBPG

• Data subscriptions : automatic staging of new data products to user-specific ftp accounts

The other main service provided by the OBPG is user support for accessing, understanding, processing, and working with the data. A great deal of this support takes place on the Ocean Color Forum ( http://oceancolor.gsfc.nasa.gov/forum/oceancolor/forum show.pl ) and through documentation available on the Ocean Color Web ( http://oceancolor.gsfc.nasa.gov/ ).

Figure 1.1: The Ocean Color Web1.3. WHAT DATA DOES THE OBPG PROVIDE? 5



## 1.3 What Data does the OBPG Provide? As mentioned, the OBPG provides ocean color data from the MODIS/Aqua, MODIS/Terra, SeaWiFS, OCTS, and CZCS sensors, and SST data from MODIS/Aqua and MODIS/Terra. Data levels range from Level-0 or Level-1A up to Level-3 Binned and mapped products. The Level-2 and Level-3 data contain geophysical products, some of which are listed below. (Hundreds of predefined products and unlimited custom products can be created using the SeaDAS software package.)

• Standard Ocean Color Products (all sensors, daytime only)

– Normalized water-leaving radiances, nLw ( λ )

– Chlorophyll, C a

– Diffuse attenuation, K d (490)

– Aerosol type and concentration

– Optical thickness, τ a

–  ̊ Angstr ̈om exponent

– Atmospheric epsilon

– Processing flags

– Cloud, land, glint, atmfail, atmwarn, chlfail, chlwarn, etc.

• Standard Ocean Temperature Products (MODIS only)

– Long-wave SST (11-12 μ m) (daytime and nighttime)

– Short-wave SST (3.9 - 4.0 μ m) (nighttime only)

– SST quality level (0-4)

• Non-standard Ocean Color Products (all sensors, daytime only)

– Alternate C

a and K d algorithms

– Chlorophyll fluorescence, FLH

– Particulate inorganic carbon, Calcite

– Inherent optical properties (various bio-optical models)

– absorption (total, phaeophytin, dissolved matter)

– backscatter (total, particulate)

– Photosynthetically active radiation, iPAR, PAR

– Euphotic depth ( Z eu , Z sd )

– Subsurface PAR at 1st optical depth, K d (PAR)

– Intermediate atmospheric correction products

– ..and many others

• Non-standard Ocean Temperature Products (MODIS only)

– Brightness temperatures (daytime and nighttime)6 CHAPTER 1. AN INTRODUCTION TO THE OBPG



## 1.4 What is SeaDAS? SeaDAS is a comprehensive image analysis package for the processing, display, analysis, and quality control of ocean color data. SeaDAS is intended for use with all of the OBPG supported sensors: MODIS/Aqua, MODIS/Terra, SeaWiFS, OCTS, CZCS. SeaDAS can also be very useful as a general scientific imagery/data analysis package. SeaDAS features include:

• Visualize and manipulate all data distributed by the OBPG

• Visualize and manipulate non-OBPG data (e.g. general HDF 4, AVHRR Pathfinder)

• Process all data from L0 or L1A through to L3 and SMI (complete source code included)

• Reproduce products identical to the OBPG standard ocean color and SST products

• NPP/VIIRS will be supported in the future

• Runs on UNIX-like systems only : Linux, Macintosh OS X, Sun Solaris, SGI IRIX

• Direct user support and extremely active user support forums

Figure 1.2: The SeaDAS Home Page1.4. WHAT IS SEADAS? 7

The SeaDAS GUI and most data visualization/manipulation functions are written in the Interactive Data Language (IDL), made by ITT Visual Information Solutions (ITT VIS). IDL is a scientific programming language and scientific environment similar in many ways to Matlab. It is not necessary to purchase IDL in order to have access to full SeaDAS functionality.

Figure 1.3: The Main SeaDAS GUI Window 

### 1.4.1 SeaDAS Modes of Operation SeaDAS functionality can be accessed in a variety of ways:

• Using the Graphical User Interface (GUI)

– Virtually all SeaDAS functionalities are accessible via the GUI. The GUI is often a good way to learn about the capabilities of SeaDAS and to work with single data files. Once a user determines his or her goal and accomplishes a task using the GUI, it is often more efficient to automate the steps by using a command-line approach.

• Using the SeaDAS command-line

– The SeaDAS command-line is available to those who have purchased a full IDL license from ITT. The SeaDAS command-line is actually an IDL command-line that provides access to both SeaDAS and IDL commands. Almost all SeaDAS processing, display, visualization, and manipulation functions can be accessed on the SeaDAS command-line in concert with IDL commands.

• Using the UNIX command-line

– All SeaDAS processing capabilities are also accessible via the UNIX command-line. This includes L0 to L3 processing (including automatic ancillary data determination and retrieval), as well as functions for subscening data files and generating true-color mapped image products. None of SeaDAS’ graphics capabilities are available on the UNIX command-line.

• Automating SeaDAS using IDL scripts and/or UNIX shell scripts

– Virtually any series of SeaDAS processing and graphics operations can be automated by writing IDL scripts. These scripts can combine both SeaDAS and IDL commands (and optionally spawn UNIX commands) to perform complex data operations. This feature does not require the purchase of IDL.

– For data processing, UNIX shell scripts can be used to easily automate the subscening and processing of multiple data files from L0 through to L3. IDL scripts can also be called from such UNIX shell scripts to access SeaDAS display, visualization, and manipulation functions. 

### 1.4.2 Components of the SeaDAS Distribution The SeaDAS distribution package is primarily made up of IDL code, C binaries and libraries, and UNIX shell scripts. The SeaDAS GUI is written in IDL code as are various image and data manipulation functions. Binaries (executable files created by compiling C and Fortran code) are used for data processing (e.g. the msl12 binary used for L1 to L2 processing). SeaDAS also makes use of HDF binaries and libraries. Shell scripts (executable text files containing various UNIX and shell commands) are mainly used as wrappers for data processing (e.g. modis L1A to L1B.csh). Other shell scripts exist as stand-alone utility scripts (e.g. the ms met.csh script for meteorological ancillary data determination and retrieval).8 CHAPTER 1. AN INTRODUCTION TO THE OBPG



### 1.4.3 SeaDAS Support As mentioned direct user support and extremely active user support forums are available for SeaDAS users. Direct support can be obtain via email ( seadas@seadas.gsfc.nasa.gov ) or by phone. However, most support occurs in the Ocean Color Forum ( http://oceancolor.gsfc.nasa.gov/forum/oceancolor/forum show.pl ), whereannouncements are made and both technical and scientific questions and discussions take place. SeaDASspecific technical questions are asked on the ‘SeaDAS: General Questions’ board, data access questions on the ‘Satellite Data Access’ board, and scientific queries on the ‘Satellite Data Products & Algorithms’ board. TIP SeaDAS GUI windows have a Help button that will spawn that window’s local help webpage. All SeaDAS-specific help documents are also available online: http://oceancolor.gsfc.nasa.gov/seadas/help.html

Figure 1.4: The Ocean Color Forum

# Chapter 2 

# An Overview of Ocean Data Levels

Introduction As mentioned, the OBPG is the designated NASA team responsible for the processing and distribution of ocean color and SST data acquired from the MODIS/Aqua, MODIS/Terra, SeaWiFS, OCTS, and CZCS sensors. This chapter discusses the standard NASA data levels used for storing ocean color satellite data. These data levels are distributed by the OBPG and/or are producible by the SeaDAS software package. 

## Goal This chapter gives an introduction to the HDF file format and briefly describes the following standard OBPG satellite ocean data levels:

• Level-0

• Level-1A

• MODIS GEO

• Level-1B

• Level-2

• Level-3 Binned

• Level-3 Standard Mapped Images 

## 2.1 HDF and HDF-EOS Data Formats OBPG Level-1A to Level-3 data files are stored in the HDF file format. HDF can be thought of as a ‘container’ that can store a variety of data types and meta data in a single file (see Figure 2.1 ). From the NASA Atmospheric Science Data Center: Hierarchical Data Format (HDF) is a data file format designed by the National Center for Supercomputing Applications (NCSA) to assist users in the storage and manipulation of scientific data across diverse operating systems and machines. NCSA developed a library of callable routines and a set of utility programs and tools for creating and using HDF files. This work is now performed by The HDF Group (THG). OBPG files are actually stored in the HDF-EOS format, a specialized form of HDF created by NASA in 1993 as a standard format for all data generated by instruments on the Earth Observing System (EOS) satellites. TIP SeaDAS is fully compatible with all OBPG HDF-EOS data files.
910 CHAPTER 2. AN OVERVIEW OF OCEAN DATA LEVELS

Figure 2.1: HDF File Example (Curtesy of The HDF Group) 

## 2.2 Level-0 Data Level-0 (L0) data files contain the raw radiance counts (digital numbers) and this is the lowest and most raw level of data normally available to end-users. L0 data is rarely utilized by end-users since the Level-1A (L1A) data is usually a simple re-organization of the L0 data into the more friendly/standardized HDF-EOS format. However, L0 data from MODIS Aqua and Terra may be desired because unlike MODIS L1A data (which has been ocean-band-subsetted), MODIS L0 data containsall 36 MODIS bands including the 7 high resolution bands, some of which may be useful for oceanic processing. As of July 2007, all MODIS L0 data is available from the single file selection page of the OBPG Level 1 and 2 Browser. A rolling 60-day archive of L0 MODIS Aqua and Terra data is also available via ftp://oceans.gsfc.nasa.gov/

. TIP SeaDAS has the ability to process L0 data to L1A for only the MODIS and SeaWiFS sensors, and can display only L0 SeaWiFS data. 

## 2.3 Level-1A Data L1A data files contain the sensor raw radiance counts (digital numbers) as well as spacecraft and instrument telemetry and calibration data. Navigation data is also included except for MODIS, in which case the geolocation data is contained in a separate file. All L1A filenames use the SeaWiFS-like convention, which indicates sensor (e.g. S for SeaWiFS, A for MODIS-Aqua, T for MODIS-Terra), sampling rate (e.g. LAC for full 1-km sampling), and time of the first scan in the file (e.g. AYYYYDDDHHMMSS.L1A LAC). The entire mission archive of L1A ocean data for all sensors is maintained online, and all higher-level products are derived from this archive. Due to the ever-changing nature of L1B calibration coefficients for active missions, it is recommended that researchers who intend to generate their own L2 products begin their processing using the L1A data (and an up-to-date version of SeaDAS).2.4. MODIS GEO DATA 11

OBPG MODIS L0 to L1A processing is performed using the standard code developed by the MODIS Science Data Support Team (SDST) and all MODIS L0 and L1A files distributed by the OBPG are 5-minute granules. For file size and bandwidth reasons, MODIS L1A files are reduced (band-subsetted) by removing excess bands and data that are not utilized for oceanic processing. A standard MODIS L1A file is ∼ 575MB ( ∼ 220MB compressed), while a band-subsetted L1A file is ∼ 215MB ( ∼ 50MB compressed). The reduced Ocean L1A file format retains the bands shown in Figure 2.2 ).

Figure 2.2: MODIS Ocean Subset Band List


## 2.4 MODIS GEO Data For the MODIS sensor only, a separate geolocation (GEO) file must be generated from an L1A file, and contains the navigation for that granule. L1B and L2 processing then requires the GEO file as an input. The naming convention for GEO files is similar to that of the L1A files, e.g. AYYYYDDDHHMMSS.GEO. GEO files are not maintained in the long-term OBPG archive since they can be regenerated as needed using SeaDAS, so only a short-term rolling archive is made available for distribution by the OBPG. For the OBPG distribution’s NRT stream, predicted attitude and ephemeris files are used to produce Quick-Look GEO files. Several days later, in the Refined processing stream, the definitive attitude and ephemeris files are used to create the final GEO version and refined data products. 

## 2.5 Level-1B Data Level-1B data files contain the calibrated at-aperture (top-of-atmosphere) radiances derived from L1A sensorcounts by applying the sensor calibration. L1B files are named similarly to L1A files, e.g. AYYYYDDDHHMMSS.L1B LAC or simply AYYYYDDDHHMMSS.L1B. For non-MODIS sensors the end-user will rarely make use of L1B files since the processing software produces a L2 file directly from an L1A input. However, for MODIS processing, generating the L1B file is a required separate step. If the input MODIS L1A file is not band-subsetted, separate high resolution L1B files will also be produced, e.g. AYYYYDDDHHMMSS.L1B HKM, AYYYYDDDHHMMSS.L1B QKM. There are differences between the MODIS L1B files produced by the OBPG and those from the MODIS Calibration Support Team (MCST). First, since ocean pixels are generally much darker than land and cloud pixels, a higher level of precision is required for ocean processing. Therefore the OBGP fine-tunes the MCST calibration coefficients for ocean data and so the ocean radiances will be slightly different (and hopefully improved). Second, the OBPG uses the ocean subsetted L1A files as input to the L1B processing so OBPG L1B files will contain only the bands listed in Figure 2.2 . However, if SeaDAS is used to process12 CHAPTER 2. AN OVERVIEW OF OCEAN DATA LEVELS

a non-subsetted L1A file, all the non-high-resolution MODIS bands will be present in the L1B file (the high-resolution bands will exist in separate L1B HKM ad QKM files). 

## 2.6 Level-2 Data Level-2 data files contain calculated geophysical values for each pixel (e.g. nLw’s, Chlorophyll-a, SST) derived from the L1B radiances by applying atmospheric corrections and bio-optical algorithms. L2 data files also contain geolocation data. Each L2 product corresponds exactly in geographical coverage (scan-line and pixel extent) to its parent L1A product and is stored in one physical HDF file. As with previous levels, the data has not been mapped and so is in “satellite view”.

Figure 2.3: Level-2 Chlorophyll-a Product L2 filenames have the form AYYYYDDDHHMMSS.L2 LAC.MODIS SST products require different processing parameters than other ocean products, therefore MODIS SST L2 files are generated in a separate processing run and are named AYYYYDDDHHMMSS.L2 LAC SST or TYYYYDDDHHMMSS.L2 LAC SST. The L2 files distributed by the OBPG contain a standardsuite of products including water-leaving radiances, chlorophyll a concentration, the diffuse attenuation coefficient at 490nm, and a few other products. In addition, thirty-twoflags are associated with each pixel indicating if any algorithm failures or warning conditions occurred for that pixel. These flags exist in the ‘l2 flags’ product. The separate standard MODIS SST files contain the 11 μ and 4 μ (nighttime only) SST products. Five quality levels are associated with these SST products and are stored in the ‘qual sst’ and ‘qual sst4’ products. Using SeaDAS, L2 files can be creating that contain hundreds of pre-defined products and/or custom products. Level-2 processing is performed using the Multi-Sensor Level-1 to Level-2 ( msl12 ) code, which is developed and maintained by the OBPG. msl12 is used for the standard processing of all ocean products distributed through the OBPG web browsers and ftp sites. This software is capable of retrieving oceanicoptical properties and a multitude of derived products from the observed top-of-atmosphere (TOA) radiances. For non-MODIS sensors the L1A file is input to msl12 , and for MODIS the L1B and GEO files are used as input. Full documentation, source code, and output product descriptions can be found at http://oceancolor.gsfc.nasa.gov/DOCS/MSL12/

. 

## 2.7 Level-3 Binned Data Level-3 Binned (L3b) data files contain spatially and temporally binned L2 data products. In other words, an L3b data file consists of the accumulated L2 data statistics for the specified instrument, product(s), spatial resolution, and time period. Bins can be thought of as square grid elements or grid cells. (Prior to L3b, geophysical variables are derived only for individual satellite pixels.) The statistical data provided in L3b files allow for the calculation of the mean, standard deviation, median, and mode for each L2 variable, and for certain other variables (e.g. primary productivity) which are functions of the L2 variables. The L3b data are stored in a representation of a global, sinusoidal equal-area grid (see Figure 2.4 ), and the standard OBPG-distributed bin resolutions are either 4.6km or 9.2km (certain regional products are 1km resolution). Only those bins containing data values are present in the L3b file; land bins and bins with no data are not stored. To create L3b files, the L2 files are spatially averaged into L3 Daily2.7. LEVEL-3 BINNED DATA 13

binned files using the l2bin program, and the Daily files are further composited into Weekly, Monthly, Annual, Seasonal, and Climatological time periods using the l3bin program. TIP SeaDAS can be used to create an L3b composite for an arbitrary time period, and the available SeaDAS binning resolutions are 0.5, 1, 2, 4, 9, and 36 kilometers.

Figure 2.4: Square Bins Defined by a Sinusoidal Equal-Area Projection The full suite of L2 ocean color parameters as well as three sea surface temperature parameters are available as standard temporal composites from the OBGP. Each product contains only data that has met data quality standards as indicated by a selected standard set of L2 flags and masks. SST products can contain data of varying data quality levels, but each bin will only contain the best quality data available for the time period.L3b products are stored either in a single, self-contained file, or else in separate data files known as subordinates (for bandwidth and disk space considerations). Single-file L3b products have filenames of the form IYYYYDDDYYYYDDD.L3b TTT, where I is the instrument identifier, YYYYDDDYYYYDDD are the concatenated digits for the GMT year and day of the start and end days of the binning period, and TTT is a code for the binning period length (DAY, 8D, MO, YR, etc.). For daily products, only the year and day of the data are used. For the multi-file L3b products a ‘main’ file exists, containing all product-level metadata and other data common to all the binned geophysical parameters, along with the multiple subordinate files, each of which contains the data of one binned geophysical parameter. An example of the filenames used for a multi-file SeaWiFS L3b Daily product is: S1998001.L3b DAY.main S1998001.L3b DAY.x00 S1998001.L3b DAY.x01

... S1998001.L3b DAY.x10 Although it is not necessary to know which subordinate file stores which product (SeaDAS automatically14 CHAPTER 2. AN OVERVIEW OF OCEAN DATA LEVELS

handles this), each extension number (x00, x11, etc.) is permanently assigned to a certain geophysical product. For example, the extension numbers for SeaWiFS are assigned as follows: x00 −→ nLw 412 x00 −→ nLw 412 x01 −→ nLw 443 x02 −→ nLw 490 x03 −→ nLw 510 x04 −→ nLw 555 x05 −→ nLw 670 x06 −→ angstrom 510 x07 −→ chlor a x08 −→ K 490 x09 −→ eps 78 x10 −→ tau 865
TIP L3 Binned data products are stored as VDATA HDF objects within the data files, so any HDF utility such as vshow can be used to obtain information about the contents of the data files. More L3b documentation including algorithms used for spatial and temporal binning are listed in the OBPG Algorithms and Products FAQ: http://oceancolor.gsfc.nasa.gov/forum/oceancolor/topic show.pl?tid=1959 

## 2.8 Level-3 Standard Mapped Images A Level-3 Standard Mapped Image (SMI) is an equidistant cylindrical projection of the arithmetic means derived from the statistical data of one Level-3 Binned geophysical product. (The equidistant cylindrical projection is also called the equirectangular projection or geographic projection.) Therefore SMI products are image representations of binned data products over the period covered by the parent product. The OBPG distributes global SMI maps at 4.6km (4320 × 2160) and 9.2km (8640 × 4320) resolution to match the L3b standard resolutions. Grid points for the entire globe are present in the data files, including an assigned fill value for land and missing data points. SMI files are distributed both as HDF files and as PNG (Portable Network Graphics) image files. The SMI HDF product files are created using the smigen program.

Figure 2.5: 8-Day Level-3 Standard Mapped Image (MODIS Aqua Chlorophyll- a , June 2007)2.8. LEVEL-3 STANDARD MAPPED IMAGES 15

All of the OBPG-distributed SMI products are stored as 16-bit integers (scaled down from the 32-bit floatingpoint L3b products). Due to scaling of the L3b data values and problems that may arise from mapping, researchers should fully understand the issues involved with the SMI format before using these maps for scientific purposes. Often using the L3 Binned data directly instead of mapping the bins may be the best approach. TIP SeaDAS has the flexibilty to create SMI maps as 8-bit integer data, 16-bit integer data, or 32-bit floating-point data at 1, 2, 4, 4.6, 9, 9.2, or 36 kilometer resolutions.16 CHAPTER 2. AN OVERVIEW OF OCEAN DATA LEVELS

# Chapter 3 

# Obtaining Ocean Data

Introduction As mentioned, the OBPG is the designated NASA team responsible for the distribution of ocean color and SST data acquired from the MODIS/Aqua, MODIS/Terra, SeaWiFS, OCTS, and CZCS sensors (this role had been previously shared by the NASA Goddard DAAC). The OBPG offers complete historical archives for each sensor, as well as near real-time (NRT) data for active missions. The access point for all OBPG data sets is the main OBPG webpage, the Ocean Color Web ( http://oceancolor.gsfc.nasa.gov/ ). 

## Goal This chapter outlines the various data access methods available via the Ocean Color Web. Each method for data access will be briefly discussed:

• Historical Data Access

– SeaWiFS Data Access

– The Level 1 and 2 Browser

– The Level 3 Browser

– Data by FTP

• Near Real-Time Data Access

– Data Subscriptions for NRT Data

– NRT Extracts and Maps

– Data by FTP

• Citing Data Products Obtained from the Ocean Color Web


## 3.1 Historical Data Access Complete historical data archives for all sensors are available for immediate download from the OBPG servers, with the exception of certain SeaWiFS data restrictions (see below). Data from active missions are made available as soon as the processing system can ingest and process it (MODIS/Aqua and MODIS/Terra data is normally available within 2-5 hours of capture). 1718 CHAPTER 3. OBTAINING OCEAN DATA



### 3.1.1 SeaWiFS Data Access The only OBPG-distributed sensor data with access restrictions is SeaWiFS data, which is currently under a two week embargo from date of collection (per the contractual agreement with GeoEye). Therefore SeaWiFS files less than two weeks old are unavailable. All SeaWiFS data greater than five years old is publicly available, but data less than five years old is not available to the general public unless they become a SeaWiFS Authorized User. To become an authorized user one must make a (brief) request to the OBGP specifying the scientific rationale for the request along with some other information (see http://oceancolor.gsfc.nasa.gov/cgi/apply.pl?page=du ). Authorized users can then use the ‘SeaWiFS User Login’ button in the data browser to gain access to all the SeaWiFS data. On December 24, 2004, the SeaWiFS project stopped receiving global data from HRPT stations (from which the MLAC data are produced). Since that time the OBPG contract with OrbIMAGE (now GeoEYE) is only for the global GAC dataset, and a new agreement has also provided the OBGP with the coastal U.S. 1km dataset. A request for recorded LAC data can also be made to the OBPG for cruise support, but NRT MODIS 1km data is now the preferred source. For non-coastal U.S. 1km data after Dec 24, 2004, data can be purchased directly from GeoEYE.


### 3.1.2 The Level 1 and 2 Browser The ‘Level 1 and 2 Browser’ link on the Ocean Color Web homepage accesses the main browser interface for selecting, downloading, and ordering Level-1 and -2 data files (as well as MODIS L0 files). From this top-level interface, search criteria can be set and then searches launched for the matching Level-1 and -2 scenes (using the ‘Find swaths’ button or by clicking on the map).

Figure 3.1: The Level 1 and 2 Browser3.1. HISTORICAL DATA ACCESS 19

Search criteria of the data browser include:

• Sensor(s)

• Day and/or night scenes

• Geographic location defined by:

– A predefined area of interest

– User-specified area of interest (lat/lon box)

– Scenes directly under mouse click on global map

– Radius about mouse click on global map

– Radius about specified lat/lon

– Minimum percent of swath falling within area of interest

– Date range (contiguous or non-contiguous) When using the data browser, a ‘Help’ button is available in the upper-righthand corner of each different type of browser page to provide help topics for all the functionalities on that page. Since this help feature details all of the minute functions of the browser, these details will not be discussed here. After a search has been launched using the ‘Find swaths’ button or by clicking a location on the global map, the search results will be displayed on a new browser page. If only one swath was found, then that swath’s files will be listed as hyperlinks for immediate download along with thumbnail browse images of the data. If more than one swath matches the search criteria, the results page will display multiple matching swath filenames and thumbnails (10 per page by default). An individual swath can be selected by clicking on its filename link, or a swath can be added to a user’s ‘shopping cart’ by clicking the asterisks link (“****”). At any time clicking the ‘ORDER DATA’ button will take the user to the Scene Order Form page.

Figure 3.2: Level 1 and 2 Browser Search Results20 CHAPTER 3. OBTAINING OCEAN DATA

On the Scene Order Form page the order can be viewed and the user must specify:

• An email address

• Whether or not to extract a specific region from the data files

• Data levels desired

• Level-2 Data products desired

Figure 3.3: Level 1 and 2 Browser Order Form Next, the ‘Review order’ button is clicked to continue to the Order Review page that will list all files to be staged. If the order looks correct, the user can then click the ‘Submit Order’ button to complete the Order. Once an order is submitted the OBPG server will begin staging the requested files and send an email notification when the files are available for download. The entire ordering and staging process is completely automated so many orders will be available within minutes of submission.


### 3.1.3 The Level 3 Browser The ‘Level 3 Browser’ link on the Ocean Color Web homepage accesses the interface for selecting and downloading the entire Level-3 global ocean color data set for many parameters and time periods. The Level-3 files in this browser have been converted from Level-3 Binned data files to Standard Mapped Images stored both as digital data in HDF formatted files and as PNG images. Both 4km and 9km data are available. A variety of standard and evaluation products can be selected, and clicking on the timeline will set a start date for products to be displayed. Below the timeline is a table of thumbnail images depicting global projections of the selected product type during various time periods. Next to the thumbnails are hyperlinks to the 4km (4320x2160) and 9km (8640x4320) HDF and PNG files. Each column in the table is associated with time periods of a fixed length such as a year, a season, a month, or an eight-day ‘weekly’ period. Clicking on the3.2. NEAR REAL-TIME DATA ACCESS 21

Figure 3.4: Level 3 Browser heading of a column will toggle back and forth between displaying and not displaying the images in that column. The ‘Help’ link in the upper-righthand corner of the browser gives more detailed help instructions. TIP The timeline is implemented as a client-side image map so as the pointer is moved along the timeline, changing dates can be viewed in the status line of a web browser. 

### 3.1.4 Data by FTP Along with web browser (html) access, the OBPG also hosts an anonymous ftp server, oceans.gsfc.nasa.gov

. This ftp site contains the most popular data products including:

• A 60-day rolling archive of recent MODIS Aqua and Terra data (L0, L1, GEO, L2)

• The complete Level-3 Binned data archive for all sensors

• The complete Level-3 Standard Mapped Image archive for all sensors

• A merged Aqua/SeaWiFS 9km chlorophyll product

• Ancillary products (e.g. METOZ, OISST, ATTEPH, etc.) 

## 3.2 Near Real-Time Data Access As opposed to historical data access, the OBPG also offers services for data users interested in receiving NRT data from active missions. Currently, the primary NRT data source is from the MODIS Aqua and Terra sensors. Typical latency for MODIS data is 2-5 hours following satellite observation. This minimal latency allows the OBPG servers to be used as a global MODIS virtual ground station. As mentioned, it is also possible to make a request for small amounts of NRT SeaWiFS recorded LAC data for cruise support.22 CHAPTER 3. OBTAINING OCEAN DATA



### 3.2.1 Data Subscriptions for NRT Data Data subscriptions can be used to automatically stage new Level-1 and Level-2 data products to user-specific ftp directories. Subscriptions are simple to create and consist of a defined region for which data are made available as they are processed. This option is intended for investigators who wish to receive all future data for a region. The subscription does not provide archived (historical) data to the user; for archived data the Level 1 and 2 Browser should be used. Data subscriptions can be created for limited geographic regions, allowing users to receive L1A, L1B, and L2 data extracts for their area(s) of interest within 2-5 hours of satellite observation. Once a subscription is set up along with automated downloads, this service can mimic an actual global ground station for each user. Data types available through the subscription service are:

• Aqua Level-1 and Level-2

• Terra Level-1 and Level-2 (SST only)

• SeaWiFS Level-1 and Level-2

• Associated ancillary data (MET, OZONE, attitude and ephemeris files) There is also an option to waiting until the refined processing has occurred (i.e. waiting until the data are processed with the optimal ancillary data), or receiving data in near real-time. Typically, refined processing occurs 3-5 days after the data are received. The status of an existing subscriptions can be checked via a web interface as well. If both refined and NRT data is desired, users can simply make two separate subscription requests. The same can be done to obtain both daytime and nighttime granules. An end date can be entered for the subscription if your research interests are limited temporally (i.e. for the duration of a cruise). If no end date is specified, the subscription will continue for the life of the mission. Also, if a subscription has expired, it can be restarted again by simply entering an email address and clicking the ’Renew Subscription’ button. This will retrieve a listing of all previous subscriptions made under the email address, and allowing selection of those to renew.

Figure 3.5: Data Subscription Form3.3. CITING DATA PRODUCTS OBTAINED FROM THE OCEAN COLOR WEB 23



### 3.2.2 NRT Extracts and Maps The NRT map and extraction utility (see Figure 3.6 ) allows users to directly access the NRT image support system in order to create regions and requests for both maps (PNG and/or JPG formatted mapped products) and data extraction (HDF extracts). The first step in the map and extraction process is to select a region. Users may either choose from a pre-defined list of regions, or define a new region. Pre-defined regions are fixed, and cannot be edited by users and user-defined regions are only usable/editable by the user who created them. Once a region is selected, a request for maps and/or data extraction must be defined. At this stage, the user chooses maps (PNG and/or JPG formatted mapped images) and/or L1/2 HDF data extracts. The following options may be defined for each map request:

• Image Width

• Add a coastline

• Add a graticule frame

• Add lat/lon gridlines

• Add a colorbar

• Add a label to the image containing the parent filename

• Threshold for minimum percent of valid pixels (ocean retrievals)

• Product selection Users may opt to have JPEG/PNG images, and/or digital data (HDF) extracts of Level-1 and Level-2 files created. Images can be sent to the user via email or placed on the OBPG anonymous FTP site for download. All HDF data will be place on the anonymous FTP site for download. NRT images from SeaWiFS are available only to authorized SeaWiFS data users who have received permission to receive real-time image support. 

### 3.2.3 Data by FTP As mentioned earlier in this chapter NRT data is available from the OBPG ftp server oceans.gsfc.nasa.gov

. 

## 3.3 Citing Data Products Obtained from the Ocean Color Web Data products retrieved from the OBPG should be cited as follows: Feldman, G. C., C. R. McClain, Ocean Color Web, < SENSOR > Reprocessing < reprocessing # > , NASA Goddard Space Flight Center. Eds. Kuring, N., Bailey, S. W. < Access DATE >
. http://oceancolor.gsfc.nasa.gov/

• replace < reprocessing # > with the appropriate reprocessing version (e.g. 5)

• replace < Access DATE > with the date of access

• replace < SENSOR > with the appropriate sensor (e.g. SeaWiFS)24 CHAPTER 3. OBTAINING OCEAN DATA

Figure 3.6: NRT Extracts and Mapping Form

# Chapter 4 

# The SeaDAS GUI

Introduction Most SeaDAS functions are accessible via the SeaDAS Graphical User Interface (GUI). This chapter will overview the SeaDAS Main Menu window which gives access to all GUI functionality. Note that virtually every function available through the GUI also has a command-line equivalent. 

## Goal The goal of this chapter is to introduce the primary functions of the SeaDAS Main Menu

. 

## 4.1 Starting the SeaDAS GUI Starting SeaDAS on the UNIX command-line without any extra arguments will spawn the SeaDAS Main Menu (see Figure 4.1 ). This window is comprised of the Display button, the Process , Utilities , Update , Help menus, and the Quit button. Note that the SeaDAS GUI requires the terminal’s display to be set to an X server.

Figure 4.1: SeaDAS Main Menu Window The SeaDAS GUI and most of its display functionality use the Interactive Data Language (IDL), a general purpose computer language and data analysis environment distributed by ITT Visual Information Solutions (ITT VIS). However, it is not necessary to purchase IDL to use runtime SeaDAS, which uses a free IDL ”embedded license”. Running SeaDAS in this mode will take slightly longer to start up, but thereafter will run as fast as with a full IDL development license. All SeaDAS functions behave identically in runtime and non-runtime mode. SeaDAS is started as follows (where % is a UNIX command-line prompt):

• If you have not purchased IDL, start SeaDAS in runtime mode: % seadas -em

• If you have purchased and installed IDL: % seadas
2526 CHAPTER 4. THE SEADAS GUI



## 4.2 The Display Button Clicking the Display button will spawn a file selection window to choose a file from which individual data products can be loaded and later displayed. SeaDAS will attempt to automatically detect the file-type, and if unsuccessful, will assume it to be a flat binary file. File-types supported are:

• MODIS L1A to L3

• SeaWiFS L0 to L3

• MOS, OCTS, CZCS L1A to L3

• AVHRR Pathfinder V4 and V5

• SeaDAS Mapped (HDF files containing projected products)

• HDF 4 (including navigation functionality if lat/lon SDs exist)

• PNG image files

• Flat binary data files


## 4.3 The Process Menu
The Process menu provides access to all of the SeaDAS processing functions. This menu is broken down by sensor, and Figure 4.2 shows the MODIS processing submenu. Note that each sensor submenu is organized from lower to higher data level processing operations.

Figure 4.2: The Process Menu



## 4.4 The Utilities Menu
The Utilities menu provides access to a variety of SeaDAS utilities for loaded and/or displayed products. The Data Visualization and Data Manipulation submenus shown in Figure 4.3 access most of the analysis functions available in SeaDAS.4.5. THE UPDATE MENU 27

Figure 4.3: The Utilities Menu 

## 4.5 The Update Menu
The Update menu provides functions for updating MODIS Aqua and Terra calibration LUTs used in L1A to L1B processing. (To fine tune calibration for ocean products the OBPG continuously modifies the standard MCST L1B LUTs to reduce detector striping artifacts and improve temporal extrapolation.) The Update menu can also update the utcpole.dat and leapsec.dat ancillary files, though the processing software itself will detect and update these files as well.

Figure 4.4: The Update Menu


## 4.6 The Help Menu
The Help menu provides access to the main SeaDAS help pages, tutorials, demos, and online help. Also note that clicking the Help button in any SeaDAS window will spawn a separate help page for that window in a web browser. 

## 4.7 The Quit Button Clicking the Quit button will immediately close all SeaDAS GUI windows and completely exit SeaDAS, returning the user to the UNIX command prompt.28 CHAPTER 4. THE SEADAS GUI

# Chapter 5 

# Displaying Data with SeaDAS

Introduction A primary functionality of SeaDAS is its image display capabilities. There are various data visualization and manipulation functions available in either the GUI or via the SeaDAS command-line. This chapter will focus on the basic GUI operations involved in displaying data. 

## Goal The goal of this chapter is to introduce very basic SeaDAS display functions by way of the following exercises:

• Loading satellite data products

• Displaying a loaded product

• Using the roam and zoom functions

• Using the cursor position display function

• Rescaling the values of the displayed data The data referred to in this and subsequent chapters can be found in the example data directory 

## 5.1 Starting SeaDAS

• If you have not purchased IDL, start SeaDAS in runtime mode: % seadas -em

• If you have purchased and installed IDL: % seadas 

## 5.2 Loading Satellite Data Products
From the SeaDAS Main Menu , click the Display button and then choose S2006088174413.L2 MLAC using the file selection window. This will bring up the Product Selection window.
2930 CHAPTER 5. DISPLAYING DATA WITH SEADAS

Figure 5.1: Product Selection Window

Figure 5.2: Band List Selection Window Choose the chlor a product and click Load . This will bring up the Band List Selection window. Each product loaded into SeaDAS will be listed in this window as a separate “band”. To view information about the loaded data product, click Band List Selection ⇒ Band Info

. From the Band List Selection window, click Display to view the data product in a new Product Display window. 

## 5.3 The Roam Window In most cases the displayed image will be larger than theviewable area. The viewable area can be changed by dragging the sides (or corners, this is OS dependent). One may also scroll around the image using the scroll bars on the bottom and left sides of the Product Display window, but this will often prove inadequate. To view the entire image at once, the Roam Window must be used. From the Product Display window, select Functions ⇒ Roam Window On . This will open a new Roam window with the full image scaled so as to be displayed in its entirety. A box outline in this window will show the portion of the loaded image viewable in the Product Display window. With the cursor placed over this box, left-clicking and dragging the box will change the viewable contents of the Product Display window. 

## 5.4 The Zoom WindowAlternatively, you may wish to zoom in on a feature observed in the Product Display window. To do this select Functions ⇒ Zoom Window On from the Product Display window. This will open a new Zoom window with a small portion of the Product Display window zoomed (initially) by a factor of 4X. Similar to the Roam window, a box outline showing the portion5.5. CURSOR POSITION 31

of the loaded image viewable in the Zoom window will be displayed in the Product Display window. The magnification of the zoom window can be changed from 1 to 16X by placing the cursor in the Zoom window and using the middle or right mouse button to cycle up or down in magnification.

Figure 5.3: Roam and Zoom Windows


## 5.5 Cursor Position

Figure 5.4: Cursor Position Window It is possible to see the actual data value for the pixel under the mouse cursor by selecting Functions ⇒ Cursor Position from the Product Display window. This will spawn a new Cursor Position window which will display the value for the pixel under the cursor in the Product Display window, as well as the Roam and Zoom windows. By default, the data displayed is interactive, that is, as the cursor is moved over the image the values displayed will correspond to the current cursor position. Alternatively, you may select the Mouse button option in the Cursor Position window to only display values for pixels when the left mouse button is clicked.32 CHAPTER 5. DISPLAYING DATA WITH SEADAS



## 5.6 Rescaling the Displayed Image When a data product is initially displayed in SeaDAS, the data is displayed using an indexed color look-up table consisting of only 197 separate colors. The minimum data value is set to the first color in the look-up table and the maximum data value is set to the 197th color. (For more details see the SeaDAS Color Look-Up Tables chapter.) If the product being displayed happens to be a standard OBPG product then SeaDAS will automatically ”scale” the data to a pre-defined minimum and maximum value, meaning all data values below the pre-defined minimum will be set to the first color in the look-up table and values above the pre-defined maximum will be set to the 197th color. The look-up table will also be set to either a linear or logarithmic scale-type depending on the product. For example, chlorophyll-a products are scaled to have a min/max of 0.01/64.0 mg · m − 3 and set to a logarithmic scale-type. If the data product is not recognized by SeaDAS to be a standard OBPG product then the product will not be scaled and a linear scale-type will be used. TIP The text file $SEADAS/config/seadas defaults is used to store default scaling information and can be modified by the user.

Figure 5.5: Window for Rescaling the Image The default scaling can be manually changed, as is often done to improve the gradient of features in the displayed data product. To do this, from the Product Display window, select Functions ⇒ Rescale . This will spawn the Display Scaling Setup window which provides options for data minimum, data maximum and scale-type (Linear or Log). This window also allows the scaling to be reset to the SeaDAS defaults or to the data range of the loaded data product. Note that any scaling SeaDAS does while displaying data only affects the appearance of an image’s colors and does not affect the data itself.

# Chapter 6 

# SeaDAS Color Look-Up Tables

Introduction When an image is displayed in SeaDAS, a color look-up table (LUT) is used to assign a color to each pixel on the screen. Many pre-defined LUTs come with SeaDAS, including those that correspond to each of the standard OBPG products. It is also easy to create custom LUTs and use them with SeaDAS. 

## Goal This chapter introduces color look-up tables and methods to use and maniplulate them within SeaDAS by way of the following sections:

• Understanding Indexed Color and Color Look-up Tables

• Loading a Color Table

• Using Multiple Color Tables

• Modifying a Loaded Color Table

• Viewing and Changing Colors in a Color Table

• Saving and Loading External Color Tables

• Adding Custom Color Tables to SeaDAS 

## 6.1 Understanding Indexed Color and Color Look-up Tables When displaying images using SeaDAS an indexed color model is used to assign colors to each pixel in the image. This means each displayed image is assigned a color look-up table containing a limited number of RGB triplets that will dictate the colors of the pixels on the screen. No color information is contained in a typical indexed image. Instead, its pixel values represent indices into the assigned LUT. Colors are applied by matching these indices to corresponding RGB triplets in the LUT. Since SeaDAS is currently an 8-bit image application, a SeaDAS session has access to only 2 8 = 256 colors. Therefore only 256 total colors can be displayed at any given time within all open SeaDAS windows. By default, a SeaDAS session is configured to have two color LUTs. 197 colors are used for the first LUT and 48 for the second, so when an image is displayed using the default primary LUT, the minimum data value will be set to the 1st color in the user-selected LUT and the maximum data value will be set to the 197th 3334 CHAPTER 6. SEADAS COLOR LOOK-UP TABLES

color. The final 11 non-LUT colors are reserved by SeaDAS with 7 used for graphics and 4 for background, foreground, cursor, and one work color. The pre-defined LUTs used by SeaDAS actually contain 256 colors, but are automatically scaled down to the number of colors available, in the case of the default primary LUT, 197. However, the load color table function can handle loading fixed portions of an input color table without scaling, allowing for the preservation of fixed mask values contained in an input color table. TIP To avoid certain limitations of the 256 color restriction, users can run multiple concurrent SeaDAS sessions, giving them 256 colors per session. 

## 6.2 Loading a Color Table

Figure 6.1: Load Color LUT Window Any image displayed in SeaDAS will automatically have a color LUT applied. The default table for a new SeaDAS session is the “B-W Linear” table which is a grey gradient ranging from a black minimum to a white maximum. As mentioned, SeaDAS offers the user a wide variety of pre-defined color tables, including those that correspond to each of the standard OBPG products. Once a data product is loaded and displayed, a different LUT can be loaded by selecting Functions ⇒ Color LUT ⇒ Load LUT from the Product Display window. This will bring up a new Load Color LUT window, from which the user may select a new LUT from one of three following color table lists (available via the IDL drop-down menu directly above the color table name list):

• Standard Product Color Tables (color tables used for OBPG operational data products)

• Custom Product Color Tables (non-standard color tables including those created by the user)

• IDL Color Tables (color tables distributed with the IDL application) It is also possible to select a color table from another loaded band that contains an embedded LUT (such as a Level-3 SMI product) using the ‘Load LUT from Band’ Load button. Additionally, color tables can be loaded from an external ASCII file (RGB triplets), a previously saved SeaDAS HDF LUT file, or RGB specified IDL arrays (see the Saving and Loading External Color Tables section in this chapter. The color bar at the top of the Load Color LUT window shows the full color range allotted for the current SeaDAS session. The predefined graphics colors can be seen at the far right of the bar while the rest of the bar shows the multiple concurrent color tables that are currently loaded. With the Auto-apply radio button set to ‘Yes’ (the default), SeaDAS will immediately apply a color table when it is selected. If auto-apply is set to ‘No’, selecting a new LUT will update only the Color Bar graphic at the top of the window giving a preview of the LUT. This avoids long waits for a new LUT to load on slow computers and/or large images. Clicking the Apply LUT button or setting auto-apply back to ‘Yes’ will immediately apply the currently selected LUT.6.3. USING MULTIPLE COLOR TABLES 35

The Refresh all windows? radio buttons determine whether to refresh only the display window that spawned the Load Color window or else to refresh all open display windows. Setting this option to ‘No’ can avoid long waits for a new LUT to load in multiple windows on slow machines and/or large images. TIP To change the initial default color LUT for future SeaDAS sessions, select the new default LUT and then click on the ‘Save Selected LUT as Default’ Save button. 

## 6.3 Using Multiple Color Tables

Figure 6.2: LUT Config Window By default SeaDAS is configured with two concurrent color tables. Prior to displaying an image (by clicking the Display button in the BandList Selection window), the user can choose which color table will be applied. To do this, from the Band List Selection window, use the LUT no. pull down menu to choose the color table number. As mentioned, the two default concurrent color tables contain 197+48 = 245 colors. Though only 245 total colors are available, the number of colors assigned to each table can be redefined by the user. SeaDAS can also be configured to have from 1 to 10 LUTs, each with user-defined index ranges. Since the total number of index values is limited to 245colors, each additional color table will reduce the number of indexes available for any given color table. To configure the number of color tables and colors per table, select Functions ⇒ Color LUT ⇒ LUT Control Window from the Product Display window. This will bring up a new Color Table Configuration window that allows the user to change the number of concurrent color tables and to define the index ranges for each. 

## 6.4 Modifying a Loaded Color Table Two methods exist in the GUI to modify the currently selected color LUT. One method allows functions to be applied to the entire color table at once, and the other allows the user to modify individual colors of the LUT one at a time. 

### 6.4.1 Applying Functions to the Entire Color LUT The Load Color LUT window allows for user modifications to the selected color LUT via the Options and Function radio buttons that activate two different panes in the window for modifying the entire color table. After any modifications to the table are made, the Apply LUT button must be clicked for the change to take effect on the displayed image(s).

• Options Pane - select the Options radio button to manipulate the loaded color table by:

– The Stretch Bottom and Stretch Top sliders: These sliders increases the range of the lowest and highest color index respectively. For example, if black is the color of the lowest index and the Stretch Bottom slider is set to 50 percent, the lower half of the color table will become all black and the remaining part of the color table will contain a linearly scaled version of all the previous color ranges. Making ‘Stretch Bottom’ more than ‘Stretch Top’ inverts the color table.

– The Gamma Correction slider: This slider can be used to change the contrast within the color table. A value of 1.0 indicates a linear ramp (no gamma correction). Values other than 1.0 indicate a logarithmic ramp with higher values of gamma giving more contrast and values less than 1.0 yielding lower contrast.36 CHAPTER 6. SEADAS COLOR LOOK-UP TABLES

– The ‘Sliders:’ Independent and Gang radio buttons: When the Gang radio button is selected, the Stretch Bottom and Stretch Top sliders become connected so that moving one slider moves the other. By default the sliders are independent, but with the sliders ganged the width of the wedge can be kept constant.

– The ‘Top:’ Clip and Chop radio buttons: When set to Clip , values larger than the ‘Stretch Top’ are set to the largest color index (the 197th color in the case of the default primary LUT). If set to Chop , values larger than ‘Stretch Top’ are set to color index 0.

– The ‘Stretch:’ Indices and Intensity radio buttons: These buttons toggle color table manipulations affecting index locations versus affecting the intensity. When set to Indices , manipulations affect the mapping between color indices and color table triples. When set to Intensity , the mapping controls the intensity of each color table entry. This is a useful when displaying quantized images, where the pixel value is arbitrary and does not represent an intensity. In this mode, the hue and saturation remain relatively constant for a given color index.

– The Reverse , Restore , and Replace buttons: The Reverse button completely reverses the indices of the currently selected LUT. Restore reverts the color table back to its original state before any changes were made. The Replace button resets all sliders to their default positions while preserving any changes that have been made to the color table. This allows the user to incrementally save changes, and gives finer control of slider manipulations and/or the Function Pane’s LUT stretching function.

Figure 6.3: The Options and Function Panes for LUT Modification

• Function Pane - select the Function radio button to access a tool for finer control over color index manipulation via a LUT stretching function. Clicking the Add Point button will add a new control6.4. MODIFYING A LOADED COLOR TABLE 37

point to the stretching function line. Clicking and dragging any control point on the line will then move the point along the line and/or change the shape of the line. The first and last control points may only be moved in the vertical direction but other control points may be moved anywhere within the plot as long as they are to the right of their predecessor and to the left of the next control point. The Reset button restores a linear one-to-one transfer function. Changes made to the stretching function do not automatically affect the Product Display window. To activate changes click the Apply LUT button.


### 6.4.2 Viewing and Changing Individual Colors in a Color LUT For detailed, index level control over a loaded color LUT, SeaDAS provides the Modify Color Table window accessible from the Functions ⇒ Color LUT ⇒ Modify LUT Colors menu in the Product Display window. This tool allows for color tables to be interactively created and modified. Changes made to the LUT will not affect display windows until the Redraw button is clicked. To alter an individual color, simply click on a color and then adjust the Red, Green, and Blue sliders (CMY, HSV, and HLS color systems can also be used).

Figure 6.4: Modify Color Table Window It is also possible to interpolate the range between two color indices to create smooth color transitions. To do this select a first index, optionally modify its color, and then click the Set Mark button. Next select a second index, optionally modify its color, and then click the Interpolate button to smoothly interpolate colors between the mark index and the current index. Alternatively the Copy Current button can be used to make every color lying between the current index and the mark index (inclusive) the same color as the current color. The Switch Mark button exchanges the mark and the currently selected index.38 CHAPTER 6. SEADAS COLOR LOOK-UP TABLES



## 6.5 Saving and Loading External Color Tables

Figure 6.5: Save Color Table Window It is possible to save the currently loaded (and potentially modified) SeaDAS color look-up table to an external file for future use. This is done by selecting Functions ⇒ Color LUT ⇒ Save LUT from the Product Display window. The color LUT can be saved to a new ASCII file or as a palette in an new HDF file. It can also be saved by replacing or appending a palette in a pre-existing HDF file. Betaware that only the data portion of the displayed image’s LUT will be saved (colors 0-196 if it is the default first LUT), and this portion will be interpolated to 256 output RGB values. Flag text boxes in the Save Color Table window allow the user to specify a range of color indices from both the top and bottom of the color table to be output directly, without any interpolation. This is useful if flags or masks are assigned to specific indices. It is also possible to load a color look-up table from an external file using the Load Color LUT window (accessed by selecting Functions ⇒ Color LUT ⇒ Load LUT from a Product Display window). The filename containing the LUT can be entered in the ‘Load LUT from ASCII or HDF file’ text box, or a file can be chosen using the ‘Select’ button. Clicking the ‘Load’ button will then load the LUT from the file.

Figure 6.6: Custom Color Tables When loading a color table from a file, SeaDAS linearly scales the 256 RGB values contained in the file into the data portion of the current SeaDAS color table (197 or 48 colors for the first and second default LUTs respectively). As with saving color tables, numbers can be entered in the flag text boxes to specify a range of color indices from both the top and bottom of the color table to be loaded directly from the file, without any scaling applied. 

## 6.6 Adding Custom Color Tables Custom color tables can be easily created and then added to SeaDAS so that they are accessible from the SeaDAS GUI. To add a custom color LUT to SeaDAS: 1. Create an ASCII file containing 256 8-bit RGB space-separated triplets, one per line (e.g. 255 0 255). This can be done within SeaDAS by saving a modified color table as an ASCII file. It can also be done by manually creating the ASCII file using a Unix text editor. 2. Insert one line at the top of the ASCII file specifying a name for this new LUT. (The file will now have 257 lines.) 3. Move this text file into the directory for custom tables: $SEADAS/data/common/luts/custom/
This new LUT will now be available in the LUT list when the Custom Product Color Tables menu option is selected in the Load Color LUT window (see Figure 6.6 ).

# Chapter 7 

# SeaDAS Graphic Overlays

Introduction SeaDAS has the capability to overlay various types of vector graphics on displayed images. Graphics can be useful for data visualization, annotations, and also for isolating specific data pixels of interest for further analysis. SeaDAS offers graphics functions for overlaying coastlines, lat/lon grids, contours, vectors, text annotations, and user created drawings. Other functions can be used to ‘mask’ certain data pixels based on user-defined criteria (e.g. data value ranges, processing flags, etc.). Seven independent, color-configurable graphics planes are available for use. 

## Goal This chapter introduces the basic functions for configuring/controlling graphics, and outlines the methods for creating, loading, and saving the following types of graphic overlays:

• Latitude/longitude gridlines, coastlines, and landmasks

• Contour lines

• Masks based on ranges of data values

• u,v vectors

• Text annotations and drawings 

## 7.1 Configuring and Controlling SeaDAS Graphics Creating a graphic in SeaDAS is as simple as displaying a data file that contains geolocation information and selecting Functions ⇒ Coastline from the display window. SeaDAS graphics are not initially permanently embedded into the displayed data, but are instead overlayed on the image in a separate ‘plane’. After overlaying graphics it is then possible to access, or even modify data lying under (or alternatvely, not covered by) the graphics. It is also possible to ‘flatten’ the image by saving both the displayed graphics and data together in a raster-type image such as a PNG file. SeaDAS graphics can be configured and controlled using the display window’s Functions ⇒ Graphics menu (see Figure 7.1 ). From this menu graphics can be erased, temporarily turned on and off, loaded, saved, copied to another window, or assigned user selected colors. 3940 CHAPTER 7. SEADAS GRAPHIC OVERLAYS



### 7.1.1 Modifying Graphics Colors Seven independent graphics planes are available in SeaDAS and each of these can be assigned any color using the Modify Graphics Colors window. This window can be accessed via the Functions ⇒ Graphics ⇒ Modify Graphics Colors or Setups ⇒ Graphics menus. Any changes to the graphics palette will affect all currently displayed images.

Figure 7.1: The Graphics Menu and the Modify Graphics Colors Window To modify the color of a graphic, select the graphics color to be modified using the Current Graphics Color slider or by clicking the desired graphics color box. After choosing the color to be modified, manipulate the color sliders to create a new color. The Current Color box will dynamically display the new working color as it is being mixed. This color will not be overwritten in the graphics palette until the Update button is clicked. The default sliders control RGP triplets, and the Select Color System menu allows for the following color systems to be utilized:

• RGB: Red, Green, Blue

• CMY: Cyan, Magenta, Yellow

• HSV: Hue, Saturation, Value

• HLS: Hue, Lightness, Saturation After completing modifications to the graphics colors, clicking the Refresh Display Windows button will apply these changes to the graphics in all currently open display windows. TIP Use the loadgp procedure to modify SeaDAS graphics colors via the SeaDAS command-line. Also, the
‘ loadgp, /reinit ’ command will reload the default seven graphics colors.7.2. TYPES OF GRAPHICS 41



### 7.1.2 Controlling Graphics

Figure 7.2: Graphics Control Window Selecting Functions ⇒ Graphics ⇒ Graphics Control Window allows the user to interactively:

• Turn specified graphics colors on and off

• Erase specified graphics colors permanently

• Define a new graphics area as being the complement of existing graphics areas. Within the Graphics Colors Selection section the user can select which graphics colors to operate on in the Functions section. Clicking Turn On or Turn Off will thentemporarily turn graphics on or off for the selected colors. Clicking the Erase button will permanently erase all selected graphics colors. To create a brand new graphicthat covers the complement (inverse) area of those graphics colors specified, first enter the number of the new graphic to be created in the Color text field and then click the Complement button. Note that graphics can also be turned on/off or erased directly from the Functions ⇒ Graphics menu. 

### 7.1.3 Copying Graphics

Figure 7.3: Copy Graphics Window The Copy Graphics window enables graphics to be copied from one display window to another. All graphics in the source window or only those graphics colors specified may be copied to the destination window. To perform the copy, enter the source ( From Window ) and destination ( To Window ) windows in the text boxes and select the graphics numbers/colors to be copied. Next, choose one of the three graphics copy modes:

• Overlay: Overlay copied graphics on top of existing graphics in the destination window.

• Underlay: Underlay copied graphics underneath existing graphics in the destination window.

• Replace: Replace all graphics in the destination window with the selected graphics in the source window. Finally, click the Go button to carry out the window-to-window graphics copy operation. Note that if the source and destination windows have different dimensions, the copied graphics will be aligned at the top left-hand corner of the window and the graphics will also be truncated if necessary. 

## 7.2 Types of Graphics This section briefly outlines the various types of graphics that can be created using SeaDAS. For a few in-depth examples of more advanced graphics operations see the Advanced Graphics Overlays chapter. Also note that clicking the Help button in any of the functions’ windows will display local help webpages included with SeaDAS.42 CHAPTER 7. SEADAS GRAPHIC OVERLAYS



### 7.2.1 Latitude/Longitude Gridlines, Coastlines and Landmasks

Figure 7.4: Gridline, Coastline, and Landmask For displayed data that is georeferenced (includes geolocation data), SeaDAS has functions to overlay latitude/longitude gridlines, and high-resolution ( ∼ 1km)coastlines and landmasks. To overlay these graphics simply select Functions ⇒ Grid , Functions ⇒ Coastline , or Functions ⇒ Landmask from the display window.By default, these three graphics are assigned to graphics color ‘1’ (red), but they can be reassigned to separate graphics planes with customized colors as shown in Figure 7.4 . This can be done using a separate configuration windows for each graphic available by way of the Setups ⇒ Grid , Setups ⇒ Coastline , and Setups ⇒ Landmask menu selections.Using the coastline configuration window, various linestyles can be selected, and if the displayed product is mapped then rivers, continents, countries, and US statescan be overlaid. The grid configuration window allows adjustment of lat/lon intervals, line-style and thickness, as well as font selection for labelling. TIP To access these three graphics functions on the SeaDAS command-line, use the grid , coast , and landmask procedures.


### 7.2.2 Contour Lines Selecting Functions ⇒ Contour from the display window will spawn the Contour Main Window . This function can be used to generate a contour plot either on the displayed source image, or in a new separate plot window (in which the source image can also be included).

Figure 7.5: Using the Contour Function to Overlay Bathymetry Contours on an SST Product7.2. TYPES OF GRAPHICS 43

Figure 7.5 shows the main contour window and a contouring example that makes use of the 2-minute resolution bathymetry database included with SeaDAS. (See the Advanced Graphics Overlays chapter for a step-by-step example of how to do this.) There are various options available for the contour function including:

• automatic or user-defined contour levels and annotations

• contour line color, thickness, and style control

• ability to color-fill contour levels, each with a different color

• use of either raw or geophysical data values as the source for contouring

• a variety of plotting options if a separate new plot window is chosen
TIP As with all SeaDAS GUI windows, clicking the Help button in the Load Color LUT window will spawn that window’s local help webpage. All SeaDAS-specific help documents are also available online: http://oceancolor.gsfc.nasa.gov/seadas/help.html 

### 7.2.3 Graphic Masks Based on Ranges of Data Values It can be very useful to isolate specific data values in an image for the purpose of data processing or analysis. This process is referred to as ‘masking’ the data. There are a variety of ways to perform masking in SeaDAS, and the Paint Color (Density Slice) GUI function is one simple method. This function performs ‘density slicing’, dividing the range of values in the displayed image into intervals and assigning a graphics color to each interval. This may aid in the analysis of the image, and the graphics created may be used as masks for further operations. The function is accessed from the SeaDAS Main Menu window via the Utilities ⇒ Data Visualization ⇒ Paint Color (Density Slice) menu selection.

Figure 7.6: The Paint Color (Density Slice) Function44 CHAPTER 7. SEADAS GRAPHIC OVERLAYS

To begin creating density slices, the Paint - Density Slice window (see Figure 7.6 ) can be used to create a list of individual raw or geophysical data ranges each with an associated color. Entries can be added one at a time, or if the range sizes are equal, multiple range entries can be added at once. As range entries are added they appear in the list pane. Clicking the Apply button will then generate graphic slices on the indicated display window. Once the desired density slices have been applied, they can be turned into one or more permanent graphics (called blotches or masks) using the Function Menu . This menu also offers a variety of other interactive operations. The Save and Restore buttons allow for saving and loading of lists (data types, density slice ranges, and their corresponding colors in red, green, and blue attributes) via ASCII files. Note: To perform this function, SeaDAS must be configured with at least 2 color tables, the last of which will be used to display the colors of the density slice ranges. Color conflicts may arise if this function is activated while other display windows are using the last color table, or if other display functions are being utilized at the same time. TIP After creating a mask on a mapped image, the graphic can be saved and then reloaded/applied to other mapped images created with the same projection and dimensions.


### 7.2.4 u,v Vector Graphics

u,v vectors (often used to denote wind or current velocity) can be overlaid as graphics on images whose pixels are geographically equidistantly spaced, i.e. regularly gridded data (e.g. equi-distant rectangular projection, equi-distant cylindrical projection). Using Functions ⇒ Vector Overlay , u,v data can be loaded from an ASCII file, from a loaded band, or directly from IDL variables. As with the image the u,v data also must be stored on regular grids.

Figure 7.7: Vector Overlay Setup and Read ASCII File Windows The user can configure the plotted vectors’ graphics properties such as color, thickness, length, etc. A subsampling rate for the u,v input data can be used to display fewer vectors, and a maximum vector length can also be specified, to exclude vectors greater than a certain magnitude ( √ u 2 + v 2 ). The maximum vector length is also printed to the terminal when the vectors are plotted. TIP Use the command-line vector procedure to access all features of the Vector Overlay GUI function.7.2. TYPES OF GRAPHICS 45

As mentioned SeaDAS can use data from loaded bands to construct the u,v vectors. One example of this method would be to load a standard NCEP ancillary HDF file’s z wind and m wind products and use them as the u and v vector components respectively. Figure 7.8 shows just such a case where wind vectors have been overlaid on a Level-3 Standard Mapped Image chlorophyll product.

Figure 7.8: Wind vectors from an NCEP meteorological ancillary HDF file overlaid on an SMI image TIP To achieve the highest vector resolution, use the SeaDAS postscript output option to save images containing vector and/or graphics data. Vector data in a postscript file are stored as annotation objects and will be redrawn at postscript resolution. 

### 7.2.5 The Annotate/Blotch Function

Figure 7.9: Annotate Window and Examples The Functions ⇒ Annotate/Blotch function allows the user to interactively annotate any displayed SeaDAS image (including zoom and roam windows) with text and/or drawings. Five types of annotation objects are available: text, lines andarrows, polygons and polylines, ellipses, and rectangles. Annotation object files can be saved and restored, and annotated displays can be written to the output image formats supported by SeaDAS. Annotation items are stored internally as objects (not bitmaps) and can be modified, deleted or added at any time. Annotation objects will berecognized as objects between multiple invocations of the Annotate window within a single SeaDAS session. To retain these dynamic objects between SeaDAS sessions, it is necessary to use the File ⇒ Save As and File ⇒ Load options in the Annotate window, since SeaDAS graphics (including any displayed annotated objects) are saved as bitmaps. The main display window, roam window, and zoom window can each be individually annotated.46 CHAPTER 7. SEADAS GRAPHIC OVERLAYS

For example, spawning the Annotate window via the Functions ⇒ Annotate/Blotch ⇒ Roam Window function allows for direct annotation to the roam window. The annotation objects will reside concurrently in both the main display window and roam windows in two different scales. Scaling is necessary in the roam window since in many cases the subsampled annotation vector objects would be otherwise unrecognizable. Users can choose to work in either scale or both scales, whichever makes sense for the application. To create high resolution annotations directly in the zoom window select the Annotate/Blotch ⇒ Zoom Window function. The high resolution zoom window and annotations can be output via the Functions ⇒ Output ⇒ Display option by specifying to output the zoom window and selecting the ‘PNG 24 Bit TrueColor’ or ‘Postscript’ output format . However, this must be done prior to exiting the Annotate window as after the window is closed, annotated objects aren’t saved at a higher scale than the full resolution window. MODES The Annotation widget has three modes of operation: Draw, Edit, and Select. - Draw Mode Allows you to design and create new annotation objects. - Edit Mode Allows you to move, resize, or otherwise change existing annotation objects. In Edit Mode, ”handles” appear on the annotation object. - Select Mode Allows you to choose an existing annotation object for editing. Select an object by clicking the left mouse button in the center of the object. When you release the mouse button, the object’s handles will appear and the Annotation widget will switch to Edit Mode. Select a mode by clicking on the appropriate Mode Button. You can also switch between Draw Mode and Edit Mode by clicking the middle mouse button. TIP fbuf ann SAVING OBJECTS Once you have created an annotation object, you must save it before going on to create another. Save objects either by clicking on the ”Save” button or by clicking the right mouse button when the annotation object to be saved is selected. If the object is not saved and you switch from one type of object to another, the unsaved object will be removed from the annotation. When the object has been saved, the mode switches automatically from ”Edit” to ”Draw”. To change a saved object, choose Select Mode, select the object and edit it. Note that once an object is selected, it is removed from the ”saved” list and thus must be saved again after modification. ANNOTATION OBJECTS The Annotation widget supports five types of annotation objects: Text, Lines and Arrows, Polygons and Polylines, Ellipses, and Rectangles. The different objects are represented by a row of bitmap buttons in the Annotation widget. To select a type of annotation, click on the appropriate button. The lower portion of the Annotation widget changes to present the controls available for that type of object. NOTE: If you switch from one type of object to another before saving an object, the unsaved object will be deleted. - Text To create a text annotation, enter the text in the field labelled ”Text”, then click with the left mouse button in the image. Your annotation text appears and the mode switches immediately to ”Edit.” Resize or rotate the annotation text using the mouse by clicking on one of the handles and dragging, or adjust the ”Size” and ”Orientation” sliders. Adjust the thickness of the text line strokes using the ”Thickness” slider. Use the ”Font” selection widget to select a font. Text can be aligned to the left, right, or center by selecting the appropriate button. - Lines and Arrows To create a line or arrow, click with the left mouse button and drag the mouse until you have created the desired line. Click on the ”Arrow” button to create an arrow or on ”Solid Arrow” to7.2. TYPES OF GRAPHICS 47

create an arrow with a filled triangle as its head. Adjust the size of the arrowhead by moving the ”Head Size” slider. - Polygons and Polylines The Polygon/Polyline tool has three sub-modes: - Draw: (the initial mode). Drag or click the left mouse button to add points to the object, connecting the most recent point to the mouse position. - Edit: Select and move a vertex or point by clicking and dragging with the left mouse button. - Delete: Remove the vertex or point closest to the cursor position when the left mouse button is pressed. Polygons can be unfilled, filled with a solid color, or filled with parallel lines by selecting the appropriate button next to the ”Fill” label. If an object is filled with lines, the angle of the lines and the spacing between them can be adjusted using the ”Line Angle” and ”Line Spacing” sliders. Choosing ”Spline” next to the ”Interpolation” label will produce objects constructed of smooth curves rather than polygons. - Ellipses To create an ellipse, click with the left mouse button at the point you wish to be the center of the ellipse and drag until the ellipse is the desired size. Adjust the eccentricity of the ellipse using the ”Eccentricity” slider. Ellipses can be unfilled, filled with a solid color, or filled with parallel lines by selecting the appropriate button next to the ”Fill” label. If an object is filled with lines, the angle of the lines and the spacing between them can be adjusted using the ”Line Angle” and ”Line Spacing” sliders. - Rectangles To create a rectangle, click with the left mouse button at the point you wish to be the upper left corner of the rectangle and drag until the rectangle is the desired size. Rectangles can be unfilled, filled with a solid color, or filled with parallel lines by selecting the appropriate button next to the ”Fill” label. If an object is filled with lines, the angle of the lines and the spacing between them can be adjusted using the ”Line Angle” and ”Line Spacing” sliders. COLOR The color of any annotation object can be changed by selecting the object and picking a new color from the Annotation widget color bar. LINESTYLE You can adjust the thickness of lines and text using the ”Thickness” slider. You can change the style of lines and shapes using the ”Linestyle” selection widget. Note that fill lines are not affected by the choice of line style. CURSOR POSITION The current cursor position with the graphics window is shown (in pixel coordinates) in the window in the center of the Annotation widget. THE FILE MENU The File menu (at the upper left-hand corner of the Annotation widget) contains the following items: - Load Load a saved annotation file into the current graphics window. A file-selection dialog allows you to select a previously-saved annotation file. When restoring objects, be sure that the window you are loading into has the same geometry as did the window from which the objects were saved. - Save Save the current annotations in a file. If an annotation file has not yet been opened or specified using the ”Save As” menu option, the file will be named ”annotate.dat” and placed in the current directory. Note that only the annotations, and not the underlying image or plot, are saved. - Save As Save the current annotations in a file. A file-selection dialog allows you to name the resulting file. Annotation files have the suffix ”.dat” by default. Note that only the annotations, and not the underlying image or plot, are saved.48 CHAPTER 7. SEADAS GRAPHIC OVERLAYS

- Write PostScript Create a PostScript file of your annotations. This menu choice reveals a submenu allowing you to choose ”Everything” or ”Objects only”. Choose ”Everything” to output the contents of the graphics window (your original plot or image) as a bitmap, and the annotation objects as PostScript drawing commands. This creates a single file and provides the best resolution. Choose ”Objects only” to save only the annotation objects. Use this mode to combine the annotations with PostScript commands that have already been output to obtain the highest resolution. To use this procedure, take the following steps: 1) Open the PostScript device and create the plot over which you wish your annotations to appear. Be sure that it has the same aspect ratio as does you drawing window. For example, if you have a 640 x 512 drawing window, and you wish to make your PostScript drawing 4 inches wide, the PostScript height or YSIZE must be set to 4.0 * 512 / 640 = 3.2 inches, e.g. DEVICE, XSIZE=4, YSIZE=3.2, /INCHES. 2) Select the window system as your plot device, and re-execute the commands that produced the background you wish to annotate. 3) Call ANNOTATE, make your annotations, and then use this option to output the PostScript. The PostScript device is not closed upon completion, as it is with the other two PostScript output options. - Export Bitmap Convert the entire contents of the graphics window (image and annotations) to a bitmap and output in the format you choose. The options available are PNG, PostScript, and TIFF. - Clear Clear the graphics window of all annotations. - Exit Exit the Annotation widget. OPTIONS BUTTON Click on the ”Options” button to select various types of PostScript output: - Standalone or Encapsulated (to be inserted into another document). - Monochrome or Color, always use Monochrome unless you have a color PostScript printer. - Portrait or Landscape. The width parameter scales the output size. The height of the output drawing is scaled from the width to retain the same aspect ratio as the original drawing window. TIP blah 

### 7.2.6 Loading Graphics from Windows, Loaded Bands, and Files blah TIP blah 

## 7.3 Output/Save
blah TIP blah Note: This is a modified version of IDL’s Annotate procedure.

# Chapter 8 

# Advanced Graphics Overlays

Introduction Advanced graphics 

## Goal Advanced graphics examples

• Bathy

• Mask and then user defined operations using IDL where procedure 

## 8.1 Bathy The following exersize introduces the Bathymetry function. By the end of this exersize, you will be able to:

• Generate a bathymetric image from a loaded (navigable) data set

• Use the Contour function to add a bathymetric contour overlay to a displayed data set

4950 CHAPTER 8. ADVANCED GRAPHICS OVERLAYS

# Chapter 9 

# Map Projection

Goal The following exersize introduces the Map Projection function. By the end of this exersize, you will be able to:

• Reproject any loaded, navigable data set into a variety of map projections

5152 CHAPTER 9. MAP PROJECTION

# Chapter 10 

# Data Output

Goal The following exersize introduces various methods for outputting data within SeaDAS. By the end of this exersize, you will be able to:

• Output displayed windows as images

• Output data in ASCII

• Output data in several flavors of binary format

• Output navigation information in ASCII or binary format

• Output graphics overlays

5354 CHAPTER 10. DATA OUTPUT

# Chapter 11 

# User Defined Operations

Goal The following exersize introduces User Defined Operations function. The User Defined Operations function provides the user with the ability to leverage the full power of IDL within SeaDAS. By the end of this exersize, you will be able to:

•

5556 CHAPTER 11. USER DEFINED OPERATIONS

# Chapter 12 

# Examining Data

Goal The following exersize introduces two methods for examining data values within a displayed window: RLine and ‘Read and Profile’. By the end of this exersize, you will be able to:

• Use the RLine function to create a track on a displayed window

• Visualize and output the data under this track

• Use the Read and Profile function to identify locations of interest and

– Display the data in a surrounding box.

– Visualize and output data in a row or column

5758 CHAPTER 12. EXAMINING DATA

# Chapter 13 

# Comparing Data

Goal The following exersize introduces various functions for comparing two or more data sets within SeaDAS. By the end of this exersize, you will be able to:

• Use the Multiple Product Data Display function

• Compare two loaded data products using the Scatter Plot function

• Compare two loaded data products using the Simple Arithmetic function

5960 CHAPTER 13. COMPARING DATA

# Chapter 14 

# The SeaDAS Ship Track Function

Introduction The SeaDAS Ship Track function provides the capability of over-plotting on a display window, external ASCII data contained in a text file. This ‘track’ data may not be cruise data, however the function’s option to connect points works well for ship track applications. The data values can be viewed and output as text, or three types of x,y plots can be created:

• track data and corresponding image data points vs. station number

• image data values lying beneath the input data track vs. image pixel number along the track

• a scatter plot of track data vs. underlying image data 

## Goal The goal of this chapter is to demonstrate all the features of the Ship Track function using an example in which a sample text file containing in situ data is imported into SeaDAS. The data will be overlaid on a satellite image, three plots will be created, and the data will be output as text. Each of these steps is detailed in separate exercises:

• Importing ASCII formatted in situ data into SeaDAS

• Displaying the loaded in situ data on an image of a loaded satellite data product

• Displaying coincident along-track in situ and satellite data

• Displaying all of the along-track satellite data

• Displaying a scatter plot of in situ vs. satellite data

• Viewing and outputting coincident satellite and in situ data

• Viewing and outputting all of the along-track satellite data 

## 14.1 Importing ASCII Formatted in situ Data Into SeaDAS The first step for working with in situ data in SeaDAS is to load the data using the Ship Track function. The Ship Track function is accessed from the image display window via Functions ⇒ Ship Track . Steps to import the data are as follows: 6162 CHAPTER 14. THE SEADAS SHIP TRACK FUNCTION

a. Load and display the chl oc2 product in the MODIS Aqua A2002275181510.L2 file. b. Spawn the Ship Track window from the image display window via Functions ⇒ Ship Track

. c. Use the Select button to choose the BIOCOMP0203 chl.dat in situ data file. d. Identify the columns for latitude, longitude, and parameter (Figure 14.1 , Boxes A—C). e. Identify any header rows to ignore (Figure 14.1 , Box D). f. Identify the number of rows to be read (Figure 14.1 , Box E). g. Ingest the file into SeaDAS using the Load button. (Note: this only loads the data and does not yet overlay it on the displayed image)

Figure 14.1: The Ship Track Function Main Window14.2. DISPLAYING THE DATA STATIONS ON THE SATELLITE IMAGE 63

The Ship Track function only accepts data as an external text file. This file must contain ASCII data formatted in any number of columns, but three of these columns must be latitude, longitude, and a geophysical data product. The columns may be in any order, since they can be specified within the Ship Track GUI (Figure 14.1 , Boxes A—C). The file may contain other columns, but only one geophysical product can be loaded at a time (Figure 14.1 , Box C). The in situ data file may also contain information presented above or below the rows of data values of interest. For example, the data matrix within a standard SeaBASS file is preceded by a series of metadata headers. Such headers must be identified using the “Lines to skip from the beginning” text box (Figure 14.1 , Box D). Footers must also be disregarded using the “Lines to read” text box (Figure 14.1 , Box E). For example, a 35 line file with 10 header rows, 20 data rows, and 5 footer rows would have values of 10 and 20 in Boxes D and E of Figure 14.1 , respectively. In Box E, a value of 0 is used to read all (non-header) rows. The “Total number of stations” and “Active stations” text boxes will be filled after the file is loaded. Also, the geophysical data product’s units may be specified using the “Units” text box. 

## 14.2 Displaying the Data Stations on the Satellite Image

Figure 14.2: Overplotting a Track Now that the image has been displayed and the in situdata has been loaded into SeaDAS, the data can be overlaid on the displayed image and output to a file as follows:
a. Select Plot Menu ⇒ Overplot track on image

. (The track will now be displayed as a graphic on top of the image.) b. Select Setup Menu ⇒ Track overplot

. c. Customize the symbol shape, color, and size. d. Choose whether or not to connect the symbols.e. Shift the symbols in the X (horizontal) or Y (vertical) direction. f. From the image display window, select Functions ⇒ Output ⇒ Display (or, Graphics)

.64 CHAPTER 14. THE SEADAS SHIP TRACK FUNCTION



## 14.3 Displaying Coincident Along-Track in situ and Satellite Data One Ship Track function feature allows for the in situ data and the corresponding image data to be plotted on a graph for comparison. For each in situ station, only the image data value of the nearest satellite pixel is considered as shown in Figure 14.3 . Steps to create this plot-type are:
a. Select Plot Menu ⇒ Track and image data

. b. Select Setup Menu ⇒ Track and image data plot

. c. Customize the symbol shape, color, and size. d. Choose whether or not to connect the symbols. e. Customize the plot titles and X- and Y-axis labels. f. Define the Y-axis ( in situ data) units. g. Define the Y-axis data range. h. Customize plot titles, X- and Y-axis labels, Y-axis units, Y-axis data range. i. Apply a slope and intercept to the satellite data. j. Choose to combine the satellite and in situ data into a single plot (default is separate plots) k. From the plot window, select Output (PNG or PostScript).

Figure 14.3: Track and Image Data Plot 

## 14.4 Displaying the Along-Track Satellite Data Another type of graph offered by the Ship Track function is a plot of the image data values lying beneath the input data track that is created by connecting the in situ data points. For this plot (Figure 14.4 ) all the satellite image data along the in situ ship track are included. To create this plot-type do the following:14.5. DISPLAYING A SCATTER PLOT OF IN SITU VS. SATELLITE DATA 65

a. Select Plot Menu ⇒ Image data along track

. b. Select Setup Menu ⇒ Image data along track plot

. c. Customize the symbol shape, color, and size. d. Choose whether or not to connect the symbols. e. Customize the plot title and X- and Y- axis labels. f. Define the Y-axis (satellite data) units. g. Define the Y-axis data range. h. From the plot window, select Output (PNG or PostScript).

Figure 14.4: Image Data Along Track Plot 

## 14.5 Displaying a Scatter Plot of in situ vs. Satellite Data The final plot-type available (Figure 14.5 ) is a scatter plot of individual track data points vs. the underlying image data. For each in situ station, only the data value from the nearest satellite pixel is considered. To create a scatter plot:
a. Select Plot Menu ⇒ Track vs. image scatter plot . (This figure cannot currently be customized.) b. From the plot window, select Output (PNG or PostScript). 

## 14.6 Viewing/Outputting Coincident Satellite and in situ Data The Ship Track function also provides two options for viewing and outputting data values and statistics as ASCII text. For the following option, in situ values and the corresponding data values from only the nearest satellite pixels are retrieved. Please refer to Figure 14.6 . Steps to view/output coincident data:66 CHAPTER 14. THE SEADAS SHIP TRACK FUNCTION

Figure 14.5: Track vs. Image Scatter Plot
a. Select Output Menu ⇒ Track and image data

. b. From the resultant GUI, select Save (file will be ASCII text). The result is a data matrix with 1 row per in situ station and the following columns:

Figure 14.6: Track and Image Text Window 1. Station number 2. Satellite pixel number 3. Satellite line number 4. Latitude 5. Longitude 6. Satellite data value 7. in situ data value
A number of bulk statistical parametersfor the full along-track series are also presented. 

## 14.7 Viewing/Outputting All of the Along-Track Satellite Data For the following data viewing and output feature, all satellite data along the in situ track are retrieved. Please refer to Figure 14.7 . Steps to view/output all of the along-track data:14.7. VIEWING/OUTPUTTING ALL OF THE ALONG-TRACK SATELLITE DATA 67

a. Select Output Menu ⇒ Image data along track

. b. From the resultant GUI, select Save (file will be ASCII text). The result is a data matrix with 1 row per satellite observation and the following columns:
1. Sequential pixel number along the entire track 2. Sequential pixel number along the current track segment 3. Satellite pixel number 4. Satellite line number 5. Latitude 6. Longitude 7. Satellite data value 8. Distance along track in kilometers A number of bulk statistical parameters for the full along-track series are also presented.

Figure 14.7: Image Data Along Track Text Window68 CHAPTER 14. THE SEADAS SHIP TRACK FUNCTION

# Chapter 15 

# Histograms

Goal The following exersize introduces the Histogram function. By the end of this exersize, you will be able to:

• Display a histogram of a loaded data set

• Use graphic blotches to generate histograms from selected areas of the displayed data set

6970 CHAPTER 15. HISTOGRAMS

# Chapter 16 

# Processing Data with SeaDAS

Introduction All of the data processing carried out by the OBPG can also be performed using SeaDAS. Since SeaDAS and the OBPG processing system use the exact same source code, it is possible for users to generate identical products to those distributed by the OBPG. 

## Goal This chapter summarizes the steps involved in ocean data processing and outlines the different SeaDAS modes that can be used to perform this processing. Examples are provided of the three approaches that can be used to process data with SeaDAS:

• Processing using the SeaDAS GUI

• Processing using the SeaDAS command-line

• Processing using the Unix command-line 

## 16.1 Are SeaDAS-generated products identical to those distributed by the OBPG? Other than very slight machine/OS dependencies (e.g. floating point math nuances), SeaDAS can generate the exact products that are available on the Ocean Color Web (we check all our platform distributions to ensure this).However, for this to occur you must be using a version of the SeaDAS binaries, data support files (e.g. calibration coefficients, gains, etc.), and ancillary data files that exactly match the versions used by production to create the file you are processing. This isn’t always easy to do. The most important thing is to have the most current version of SeaDAS. Once you have that installed you can consult the processing versions table to compare your versions with those in the forward stream of our production system. (It is possible even the newest version of SeaDAS may be a bit behind what is being used in production’s forward stream.) If your binary versions, L1B calibration look-up tables, and gains all match, then you should be getting identical product values to those of production (other than slight machine/OS dependencies) for recent MODIS products. I say recent because until a complete reprocessing occurs, a file from the Ocean Color Web may have been processed at an earlier date when versions were older than what is shown in the processing versions table. (Also, since older L1B data isn’t distributed you’ll have no way of knowing what L1B LUTs 7172 CHAPTER 16. PROCESSING DATA WITH SEADAS

were used for an older file.) Also be careful not to compare Quicklook MODIS products with products you’ve generated using Refined attitude and ephemeris, otherwise slight geolocation differences will make the data appear slightly different.If all versions appear to match and you’re still not getting an identical product, take a look in the metadata of the Level 2 file (using ”ncdump -h”). Make sure everything matches as it should.. for example the MET/OZONE input files should be exactly the same for your file as for the Ocean Color Web file. If you still get a difference, then this might indicate a problem, so please let us know and we’ll look into it. 

## 16.2 Data Processing Flow
blah

Figure 16.1: Data Processing Flow 

## 16.3 Approaches to Processing
blah 

## 16.4 Processing Using the SeaDAS GUI
blah processing SeaWiFS ocean color satellite data from raw multispectral radiance values to a mapped imagedepicting the regional distribution of chlorophyll. The processing begins with a Level-1A file containing topof-the atmosphere radiance values recorded by the satellite’s onboard radiometer. The first step is Level-2 processing which takes the ’top-of-the-atmosphere’ radiance intensities in the Level-1A file and performs16.5. PROCESSING USING THE SEADAS COMMAND-LINE 73

atmospheric corrections to derive a Level-2 file of normalized water leaving radiances (Lnw), chlorophyllconcentration, a few other geophysical parameters and quality control flags. A second step takes the geophysical data contained in the Level-2 file and maps it from the raw satellite perspective to a user-specified coordinate system (oftentimes a cylindrical system is chosen where each pixel is of equal degrees of latitude and longitude). An optional last step is to export the mapped file to a flat binary file format that is easily read by a variety of commercially available analytical software programs (e.g., IDL or MATLAB). 

## 16.5 Processing Using the SeaDAS Command-line
blah 

## 16.6 Processing Using the Unix Command-line
blah NOTE: Similar to the previous SeaWiFS processing exercise, the purpose of this lab is to present an overview of the basic steps involved in processing the MODIS data that you ordered from the Ocean Color Browser. Though the data levels and processing chain are very similar there are some distinct differences. One difference to note in this exercise is that MODIS L1A data must be processed to L1B and then on to L2. (This also occurs for SeaWiFS processing, but is hidden from the user by default.) Another difference is that MODIS L1A and L1B files require a separate geolocation file to be produced, whereas SeaWiFS always has geolocation data embedded within its data files. 

## 16.7 Ancillary Data Certain stages of SeaDAS data processing require ancillary data. This data can be refined, non-refined NRT, or Geolocation (attitude and ephemeris), Calibration (coefficient look-up tables), atmospheric correction (MET/OZONE/SST) As long as you have an internet connection SeaDAS will automatically determine the required ancillary data and download it from the OBPG servers if it doesn’t exist on the local hard disk. however, if you don’t have internet or have a large data set you are processing for the first time, you may want to download the anc data first from the OBPG servers. This section doesn’t go into details of where the data exists on our servers and what logic to use when retreiving the files, but htis info is avaiable on the OBPG website. 

### 16.7.1 Navigation Pre-MODIS sensors fine (exception SeawiFS.. elements.dat) NRT data and refined ancillary data Aqua and Terra Attitude and Ephemeris These files are either the definitive attitude and ephemeris data for MODIS Aqua and Terra, or are the near-real-time (NRT) attitude and ephemeris for Aqua. (Terra has NRT attitude and ephemeris embedded in its Level-0 data files.) Attitude and ephemeris data are required for producing geolocation files from Level 0 or Level 1A files. SeaDAS includes a feature to automatically download both definitive and real-time attitude and ephemeris files during processing. It is suggested to simply use this feature to ensure you have the correct files. utcpole.dat and leapsec.dat74 CHAPTER 16. PROCESSING DATA WITH SEADAS

The Earth motion file ”utcpole.dat” and the leap seconds file ”leapsec.dat” are required for MODIS geolocation processing and are included with SeaDAS. These files must be kept up-to-date. Though the SeaDAS processing programs will automatically download them if they’re over 14 days old, it is still suggested that they be updated on a weekly basis by running the modis update utcpole leapsec.csh script as a cron job. To quantify the errors caused by not updating these files (called ”latency”) Peter Noerdlinger has prepared an excellent document: http://newsroom.gsfc.nasa.gov/sdptoolkit/latency.html


### 16.7.2 Calibration Data MODIS LUTS blah SeaWiFS Sensor Calibration Table The sensor calibration table is comprised of a set of parameters required for applying the sensor calibration to raw (L1A) data. The table is stored as one physical HDF file that is available as a SeaWiFS product. The calibration table includes parameters that will not be changed and parameters that may be updated. Updates are performed by the OBPG and result in the appending of data to the file’s contents. Whenever it is updated, a new version of the file is made available as a product. Results of vicarious calibration studies can indicate if updates are needed to improve previous calibration parameter values or to account for changes in sensor. 

### 16.7.3 Near Real-Time Ancillary Data Products for Level-2 Processing??? 16.7.4 Near Real-Time Ancillary Data Products for Atmospheric Correction??? NRT data and refined ancillary data Products of the meteorological data - meridional wind, zonal wind, pressure, and relative humidity - and total ozone, used during the L2 operational processing, are made available by the Project. (Relative humidity is not currently used during the processing.) The meteorological and ozone data are referred to as ancillary data. These products are gridded, Equidistant Cylindrical images of, or derived from, data from other agencies. These data represent global ”snapshots” at frequencies of at least once per day and as such are considered as near real-time (NRT) data. Each product is contained in one physical HDF file. As part of its quality control procedures, the Project may modify suspect values and fill missing values of NRT ancillary data grid points. An associated ”Q/C” field is stored with each ancillary parameter image for recording any modifications to the original data. If a grid point’s ancillary data value is changed, the corresponding Q/C grid point is set equal to 1; otherwise, it is set equal to 0.meteorological and ozone information from ancillary sources. In the NRT stream, climatological meteorological and ozone data are used. The NRT Quick Look L1A, GEO, L2 products are then immediately available on the ocean color browser and in the rolling ftp archive within 6-10 hours of observation. When the definitive attitude and orbit and coincident meteorological and ozone data are received several days later, they are used in the Refined-processing stream and the L2 products are regenerated.The standard products generated for MODIS/Aqua are listed here: http://oceancolor.gsfc.nasa.gov/PRODUCTS/. Ancillary Meteorological Data This is the NCEP Meteorological (MET) ancillary data used for L1-L2 processing. The files are updated every 4 hours on ftp://oceans.gsfc.nasa.gov/METOZ/ and are organized by YYYY/DDD. The SeaDAS Level-2 processing program (msl12) requires meteorological data as an input. The input file(s) can come from either near-real time (NRT) or climatology sources. All ancillary inputs into msl12 are in the same SeaWiFS-specified HDF file format. Note: Relative humidity, although contained in the ancillary MET files, is not currently required or being used in the SeaWiFS Level-2 processing algorithm in msl12.16.7. ANCILLARY DATA 75

The default for the Ocean Data Production System is to use NRT ancillary data, whereas the current default for SeaDAS is to use the climatology ancillary data which are distributed with SeaDAS in the directory $SEADAS/data/common/. It is possible to instead specify NRT ancillary inputs when running msl12 within SeaDAS. The NRT MET data available from the Ocean Biology Processing Group have already been quality-controlled and can be input directly into msl12. The current source for MET data is NCEP. The ancqc program can be useful in displaying and optionally editing the NRT HDF files. It is also possible to view the qc arrays in the NRT files with the ancqc program. The qc arrays track if any points had been modified from the initial source values. Ancillary Ozone Data The Level 2 data processing within MSl12 also requires ozone data as an input. The files are updated every 4 hours on ftp://oceans.gsfc.nasa.gov/METOZ/ and are organized by YYYY/DDD. The ozone component of the atmosphere at a given time affects the atmospheric signal measured by a satellite and its concentration needs to be taken into account and removed from the atmospheric signal. The Ocean Biology Processing Group makes use of several sources of ancillary ozone in the processing of both SeaWiFS and MODIS data. See http://oceancolor.gsfc.nasa.gov/VALIDATION/ozone.html for more information. Listed below are the ozone data sources listed in order use: * EPTOMS: The primary source of ozone data. The Earth Probe Total ozone Mapping Spectrometer data set consists of daily global maps of total column ozone over sunlit portions of the globe. It measures backscattered UV radiances in the 310-380 nm region. * TOAST: The back-up source of ozone data. Total Ozone Analysis using SBUV/2 and TOVS) Data set combines TOVS trophospheric and lower stratospheric ozone with SBUV/2 mid-to-upper stratospheric layer ozone retrievals. * Climatology (SeaDAS defaults to the standard climatology file in $SEADAS/data/common/) NOAA OISST This is the NOAA Optimum Interpolation (OI) Sea Surface Temperature analysis archive, available at ftp://oceans.gsfc.nasa.gov/OISST/. These files can be used as input for the MDOIS L1-L2 SST processing instead of the climatological SST input data ($SEADAS/data/common/sst climatology.hdf). This data is currently used for the SST guess in the non-linear SST algorithm (NLSST). See the README file in the oceans.gsfc.nasa.gov OISST ftp directory for more information. SST is also required for certain derived product algorithms, such as the Carder IOP model. For sensors without SST capability, the OISST file can be provided as input for use in derived product algorithms. Otherwise, the climatology will be used. 

### 16.7.5 Climatological Ancillary Data Products for Level-2 Processing??? 16.7.6 Climatological Ancillary Data Products for Atmospheric Correction??? Climatologies of the ancillary data required for L2 processing have been created by the OBPG. These climatologies can be used by the L2 processing software in lieu of NRT data when the NRT data are unavailable or deemed to be of poor quality. Two climatological products, each a single HDF file, are used–one for four meteorological parameters and the other for ozone. For each of these five parameters, long-term monthly means were calculated using data from other agencies. The means, along with the associated standard deviations and number of observations, are stored as gridded, Equidistant Cylindrical images.76 CHAPTER 16. PROCESSING DATA WITH SEADAS

# Chapter 17 

# The Level-2 Flags Display

Goal The following exersize introduces L2 flags display functionality. By the end of this exersize, you will be able to:

•
Figure 17.1: Level 2 Flags Display Window

7778 CHAPTER 17. THE LEVEL-2 FLAGS DISPLAY

# Chapter 18 

# Creating True Color Images

Introduction Most ocean color sensors measure the visible wavelengths necessary to produce a ’pseudo’ true color (RGB) image, which approximates what the human eye would see looking down on the Earth from space. Such images can be useful in data analysis and presentation. SeaDAS provides the capability to generate these images in several different ways. 

## Goal This chapter introduces the methods for creating true color images with software provided as part of the SeaDAS package by way of the following sections:

• Understanding the concept of combining three visible bands to create an RGB image

• Creating an RGB ’band’ using the Load True Color Image utility

• Creating an RGB image in satellite coordinates using msl1bgen

• Creating a mapped (Plate-Carr ́e projection) RGB image using msl1tcpcbox 

## 18.1 Understanding RGB images Most ocean color sensors collect data in several different bands in the visible and near infrared part of the electromagnetic spectrum. For each band, the detector measures the intensity of the light that reaches the sensor. When these data are displayed visually, the result is a series of black and white or “gray-scale” images, which look much the same as black and white photographs taken with a series of colored filters over the lens (see Figure 18.1 ). Different features have different intensities in the various bands. For example, clouds and water appear bright in the blue bands, while land is dark. In the red and infrared bands, it is the land that is bright, while the water is dark. By combining data from just three of these bands, one each in the red, green and blue portions of the spectrum (hence the RGB moniker), a pseudo true color image can be produced. Each band is displayed in a monochromatic scale corresponding to its appropriate color. When these are appropriately combined they produce the entire range of visible colors, creating an image that is fairly close to what the human eye and brain would perceive. This is very similar to the way a color TV produces a range of visible colors on the TV screen, using only red, green, and blue dots. The data used for the RGB composite images are from L1B, the calibrated, top-of-atmosphere radiances. In the case of SeaWiFS, OCTS, and CZCS, L1A can be used as input, as the code will perform the L1B conversion internally. For MODIS the L1B and Geolocation files must be created prior to using the code described below. 7980 CHAPTER 18. CREATING TRUE COLOR IMAGES



### 18.1.1 Rayleigh correction

Figure 18.1: Generating an RGB ImageAs the photons of light pass through the atmosphere, they interact with molecules in the atmosphere. This interaction produceswhat is known as atmospheric scattering, where blue light is preferentially scattered in random directions, which is why the sky appears blue. If this scattered atmospheric contribution is notcorrected, the RGB image will appear hazy or washed out. Fortunately, this scattering component can be readily calculated using the well-known Rayleigh scattering equation and can therefore be subtracted from the data to produce a more crisp looking image. 

### 18.1.2 To Map or Not to Map The top-of-atmosphere satellite data are not in a projection mostpeople are familiar with. The curvature of the Earth, the inclination of the satellite orbit and the way the satellite sensor scans, allcombine to produce a warped image. SeaDAS provides two mechanisms to produce an RGB image of this warped satellite data ‘as is’ ( msl1brsgen as well as the GUI’s true color utility) and anothermethod which will remap the data into a more reasonable projection ( msl1tcpcbox ). Therefore, the user has the option tocreate mapped or non-mapped RGB images to suite their needs. 

## 18.2 Creating an RGB ’band’ using the SeaDAS GUI SeaDAS provides a GUI interface that allows for the creation of an RGB image which will loaded as a SeaDAS ’band’. This utility was originally intended for SeaWiFS only, although it provides the option to create the RGB image from previously loaded ’bands’, giving the user the flexibility to define what data are combined. This can be used to allow RGB images from non-SeaWiFS data to be created. The output from this function is an 8-bit image that has not had the Rayleigh correction applied. From the SeaDAS Main Window, select Utilities ⇒ Data Visualization ⇒ Load True Color Image . You can enter a SeaWiFS L1A file into the selection box, then choose which bands to use for the RGB composite. Clicking on the Load button will load an RGB composite into the SeaDAS Band List Selection window for subsequent display/manipulation.

Figure 18.2: Load True Color Image Widgets18.3. CREATING AN RGB IMAGE USING MSL1BRSGEN 81

Alternatively, you may load an RGB from three arbitrary, previously loaded bands. From the Load True Color Image window, select the ’Band List’ radio button. This will change the input to allow selection of the three RGB bands. This widget also allows for a slope and intercept to be applied to the data prior to compositing. 

## 18.3 Creating an RGB image using msl1brsgen SeaDAS provides another utility to produce a pseudo true color browse product, msl1brsgen . By default, this program produces an HDF file, navigable as any other product within SeaDAS. However, msl1brsgen can also produce a 24bit portable pixmap (PPM) image file, which can easily be converted into a JPEG or PNG image file. Usage: msl1brsgen [Optional arguments] l1 filename [geo filename] output file name

Figure 18.3: An RGB Image The first step, which is only necessary if the satellite data are from MODIS, is to generate the geolocation and L1B files; for the other sensors (SeaWiFS, OCTS, CZCS) msl1brsgen accepts L1A as input. For the following example the MODIS Aqua file A2007059122000.L1B LAC (and it’s geolocation file, A2007059122000.GEO] will be used. Since msl1brsgen ’s default behavior is to create an HDF file, the optional [-p] switch must be set in order to produce a PPM file as output. The msl1brsgen program has the ability to subsample the satellite data. The default is to subsample by a factor of 10, so a typical MODIS file at 1354 pixels by 2030 scan lines would produce an output image that is 135 by 203 pixels. This is suitable for webpage browse imagery. Higher resolution images can be obtained by changing the subsampling factor by using the optional argument [-r subsample-factor], where ’subsample-factor’ is an integer value. For example, -r 2, would subsample every 2nd pixel and scanline effectively producing a 50% scaled image. The optional argument [-a] will turn on the simplified atmospheric correction (basically, Rayleigh radiance subtraction].If a desired scanline and/or pixel range is known, the [-f first-scan-number, -l last-scan-number, -s startpixel-number, and -e end-pixel-number] options can be set to produce an extracted image. To produce an RGB browse image of A2007059122000.L1A LAC: msl1brsgen -p -r 3 A2007059122000.L1B LAC A2007059122000.GEO A2007059122000.BRS.ppm

Figure 18.4: An RGB Image with Rayleigh Correction To produce an RGB browse image of A2007059122000.L1A LAC with the data Rayleigh corrected: msl1brsgen -a -p -r 3 A2007059122000.L1B LAC A2007059122000.GEO A2007059122000.BRS atmcorr.ppm Since MODIS Aqua scans from west to east and is an ascending orbit, the above images 18.4 and 18.5 were flipped top-to-bottom and left-to-right to present the data in a normal NSEW orientation. A Netpbm program was also used to convert the PPM file to a JPEG. The Netpbm programs, pamflip and ppmtojpeg were used. From the Netpbm website: Netpbm is a toolkit for manipulation of graphic images, including conversion of images between a variety of different formats.

... For more information on what the package does, see http://netpbm.sourceforge.net/doc82 CHAPTER 18. CREATING TRUE COLOR IMAGES



## 18.4 Creating a mapped (Plate-Carr ́e projection) RGB image SeaDAS provides the msl1tcpcbox utility to enable generation of a Plate-Carr ́e mapped, pseudo true color product. As with the msl1brsgen program, the output is a 24bit PPM image. Usage: msl1tcpcbox [optional arguments] width n s w e thresh fname [geofname] ofile

Figure 18.5: An RGB Image Mapped The argument ’width’ is the output number of pixels for the image to be produced. The n, s, e, and w arguments are for indicating North, South, East and West coordinates to which the image is to be mapped. The ’thresh’ argument is the minimum percentage of valid pixels that are necessary in order for a map to actually be produced. The fname, geofname and ofile arguments are the inputL1[A—B] file, geolocation file and output filenames respectively. msl1tcpcbox 600 51.16 29.68 -7.22 26.06 0.1 A2007059122000.L1B LAC A2007059122000.GEO A2007059122000 mapped.ppm As with the msl1brsgen program, the msl1tcpcbox program accepts an optional argument, [-a], for applying a simplified atmospheric correction to the data. msl1tcpcbox -a 600 51.16 29.68 -7.22 26.06 0.1 A2007059122000.L1B LAC A2007059122000.GEO A2007059122000 mapped atmcorr.ppm

Figure 18.6: An RGB Image Mapped with Rayleigh Correction

# Chapter 19 

# Advanced Topics

For intermediate to advanced users, the two day seminar may not meet their needs. An optional third day, or alternatively, a separate advanced training seminar with a targeted focus can be held. These targeted advanced seminars may include any number of the following: a. Satellite intercomparison exercise b. Nuts and Bolts of msl12 Target audience: programmers who wish to recompile msl12, with possible user modificationsc. Time Series Analysis using SeaDAS Target audience: researchers interested in regional studies including, but not limited to environmental monitoring (e.g. Chesapeake Bay Program)d. Non-standard msl12 options e.g. Using pre-defined functional form for user-defined chlorophyll algorithm within msl12 ; modifying IOP coefficients; using alternative atmospheric correction options; using MODIS hires bands (possible separate topic) e. Creating psuedo-true color images f. Multi-sensor intercomparison

8384 CHAPTER 19. ADVANCED TOPICS

# Chapter 20 

# msl12 —In Depth

Goal The following exersize explores the m ulti— s ensor l evel- 1 to l evel- 2 processing code in depth. By the end of this exersize, you will be able to:

• Understand the components of msl12 and how each relates to the atmospheric correction and Level-2 product generation process

• Compile msl12 from the source code provided with SeaDAS

• Understand the steps necessary to modify msl12 to add a new Level-2 output product (time and interest permitting) other than very slight machine/OS dependencies (e.g. floating point math nuances), SeaDAS can generate the exact products that are available on the Ocean Color Web (we check all our platform distributions to make sure if this).However, for this to occur you must be using a version of the SeaDAS binaries, data support files (e.g. calibration coefficients, gains, etc.), and ancillary data files that exactly match the versions used by production to create the file you are processing. This isn’t always easy to do. The most important thing is to have the most current version of SeaDAS. Once you have that installed you can consult the processing versions table ¡http://oceancolor.gsfc.nasa.gov/seadas/versions.html¿ to compare your versions with those in the forward stream of our production system. (It is possible even the newest version of SeaDAS may be a bit behind what is being used in production’s forward stream.) If your versions, L1B calibration look-up tables, and gains all match, then you should be getting identical product values to those of production (other than slight machine/OS dependencies) for recent MODIS products. I say recent because until a complete reprocessing occurs, a file from the Ocean Color Web may have been processed at an earlier date when versions were older than what is shown in the processing versions table. (Also, since older L1B data isn’t distributed you’ll have no way of knowing what L1B LUTs were used for an older file.) Also be careful not to compare Quicklook MODIS products with products you’ve generated using Refined attitude and ephemeris, otherwise slight geolocation differences will make the data appear slightly different.If all versions appear to match and you’re still not getting an identical product, take a look in the metadata of the Level-2 file (using ”ncdump -h”). Make sure everything matches as it should.. for example the MET/OZONE input files should be exactly the same for your file as for the Ocean Color Web file. If you still get a difference, then this might indicate a problem, so please let us know and we’ll look into it.

8586 CHAPTER 20. MSL12 —IN DEPTH

# Chapter 21 

# Advanced Data Processing with msl12

Goal The following exersize introduces the many user customizable options available within msl12. By the end of this exersize, you will be able to:

•

8788 CHAPTER 21. ADVANCED DATA PROCESSING WITH MSL12

# Chapter 22 

# L2 comparison of SeaWiFS and MODIS-Aqua

Goal The following exersize explores inter-satellite comparisons using satellite data from two sensors over the same location on a given day. The exercise will compare SeaWiFS to MODIS-Aqua. By the end of this exersize, you will be able to:

• generate a scatter plot of SeaWiFS vs. MODIS-Aqua chlorophyll

• create a difference map of the two sensors’ chlorophyll product

• create a histogram of the ratio of MODIS-Aqua to SeaWiFS chlorophyll

• use the User Defined Band Operations function to identify common points between two mapped images First, load (and display) the SeaWiFS and MODIS-Aqua files (or, any 2 satellite files). Load the chlor a and l2 flags for both files. Load the MODIS-Aqua nLw 488 and nLw 551 (to be used in the user-defined algorithm) In the classroom, we’ll briefly review and evaluate the level-2 flags for these files. To view the level-2 flags, from the SeaDAS Main Menu use: Utilities `a Data Visualization `a Level-2 Flags Display To directly compare the 2 satellite files, they need to be reprojected to a common grid. Use Utilities ⇒ Data Manipulation ⇒ Map Projection

• select both files from the Selection List

• select your projection (we’ll use Cylindrical with the Isotropic option set)

• define your Lat Limit and Lon Limit (e.g., 40 to 45N and -75 to -65W)

• define your Output Size (e.g., 600 and 300) To simultaneously view the SeaWiFS and MODIS-Aqua data products use: Utilities ⇒ Data Visualization ⇒ Multiple Products Data Display ⇒ Geo Data View To view a scatter plot of the SeaWiFS and MODIS-Aqua data products use: Utilities ⇒ Data Visualization ⇒ Scatter Plot 8990 CHAPTER 22. L2 COMPARISON OF SEAWIFS AND MODIS-AQUA

• select the 2 mapped chlorophyll products

• modify x- and y-axis ranges

• customize colors, axis titles and styles, etc. To identify common bins, we might use a user-defined band function. Use Utilities ⇒ Data Manipulation ⇒ User Defined Operations

• data arrays defined by B# where # is the number of the loaded band

• your final output array must be named result

• you have the option to define the name of the output band

• select a band whose navigation will be used for the new product example code: v = where(B5 le 0. or B8 le 0.) b3[v] = -1. b4[v] = -1. result = B5 These new user-defined bands will need customized scales and ranges when displayed. Use Function ⇒ Rescale Typically, we use 0.01 to 100 and log-scaling for chlorophyll. For basic statistical evaluation, one might use Utilities ⇒ Data Manipulation ⇒ Simple Arithmetic

• compute simple differences, means, and summations

• customize use of Geo or Raw data

• customize Exclusion Method For more complicated statistical calculations, use (again) a user-defined band function. Utilities ⇒ Data Manipulation ⇒ User Defined Operation example code for calculating the ratio of the SeaWiFS and MODIS-Aqua data might be: ratio = B5 / B8 v = where(B5 le 0. or B6 le 0.) ratio[v] = -1. result = ratio The new user-defined ratio will also need to be rescaled: Functions ⇒ Rescale To view a histogram of these ratios, use Functions ⇒ Histogram

# Chapter 23 

# Using SeaDAS in a Time Series Analysis

Goal The following exersize outlines a method for using SeaDAS to create a regional satellite data time-series. By the end of this exersize, you will be able to:

•

91

## SeaWiFS Level-1A Data Products

1.0 Introduction This document describes the specifications of the SeaWiFS Level-1A archive products which are produced and distributed by the NASA Goddard Space Flight Center's Ocean Discipline Processing System (ODPS). The products are implemented in the Hierarchical Data Format (HDF), and HDF terminology is used in this document. These specifications are given in terms of the logical implementation of the products in HDF and are not a physical description of file contents. Therefore, HDF software must be used to create or read these products. A SeaWiFS Level-1A product is generated from Level-0 data files. It contains all the Level-0 data (raw radiance counts from all bands as well as spacecraft and instrument telemetry), appended calibration and navigation data, and instrument and selected spacecraft telemetry that are reformatted and also appended. This product is stored as one physical HDF file. Each product contains one type of Level-1A data. The type of the data is specified by the global attribute Data Type . The possible Data Type values are "GAC" for global-area coverage data, "LAC" for local-area coverage data, "LUN" for lunar calibration data, "SOL" for solar calibration data, "TDI" for data from a TDI check, "IGC" for data from an intergain calibration check, and "HRPT" for direct-readout data. (The generic term "LAC" is also used to refer to all fullresolution, recorded data, including lunar, solar, TDI, and IGC data.) Note that GAC data are subsampled from full-resolution data with every fourth pixel of a scan line (from LAC pixels 147 to 1135) and every fourth scan line being recorded. Thus, GAC data are comprised of 248 pixels per scan line, whereas all other types are comprised of 1,285 pixels per scan line. Also note that HRPT data are collected at one of many HRPT stations (global attribute, Station Name ), whereas all other data types are from dumps of the onboard flight data recorder. A catalog of all available HRPT stations is maintained on the SeaWiFS home page at http://seawifs.gsfc.nasa.gov/SEAWIFS/HRPT/HRPT_LOCATIONS.html. The SeaWiFS Project also produces a “merged LAC” (MLAC) product, which consolidates all available full-resolution (LAC and HRPT) from a single orbit. In geographic regions with multiple HRPT stations, overlapping scenes are evaluated to select a single “best quality” scan in order to eliminate duplicate scans. MLAC data may also have gaps if non-contiguous LAC and HRPT data segments were collected in an orbit. For GAC data, individual products are generated from each Level-0 GAC recording period (the Earth data collection portion of an orbit). Each such GAC product thus constitutes one scene. For HRPT data, each scene is comprised of one satellite pass. For recorded, full-resolution (e.g., LAC) data, each scene is comprised of a continuous recording of one data type. For MLAC data, each product contains the best available full-resolution data for a single orbit, without duplication.2.0 Naming Convention

The form of a Level-1A file name is Syyyydddhhmmss.L1A_ttt, where S is for SeaWiFS, yyyydddhhmmss are the concatenated digits for the GMT year, day of the year, hours, minutes, and seconds of the first scan line, and ttt is a three- or four-character data type code. For HRPT data, the form is Syyyydddhhmmss.L1A_Hhhh, where hhh is a three-character code identifying the agency and location of the HRPT station. Examples of file names for each Level-1A data type are: S2001277130655.L1A_GAC for GAC data S2004066112047.L1A_LAC for LAC data S2001103221441.L1A_MLAC for merged LAC data S2004099105941.L1A_SOL for solar calibration data S1998338002218.L1A_LUN for lunar calibration data S2004137152325.L1A_TDI for TDI check S2004141113305.L1A_IGC for intergain calibration check S2003349160330.L1A_HNSG for N AS A/ G SFC HRPT data ( Station Name = "GSFC HRPT, NASA, MD")

3.0 Global Attributes For global attributes that have constant values specific to this product type, the value is given.

3.1 Mission and Documentation Product Name (character): the name of the product file (without path). Title (character): "SeaWiFS Level-1A Data". Data Center

(character): for Station Name = "Wallops Flight Facility" or "GSFC HRPT, NASA, MD", "NASA/GSFC SeaWiFS Data Processing Center"; for all other HRPT stations, will be the same as Station Name

. Station Name (character): for all recorded data (GAC, LAC, SOL, LUN, TDI, IGC), "Wallops Flight Facility"; for HRPT stations, the station affiliation given on the web site; for MLAC data, “Merged LAC Product comprising data from multiple stations” Station Latitude (4-byte real): for Station Name = "Wallops Flight Facility", 37.9272; for Station Name = "GSFC HRPT, NASA, MD", 38.9958; for all other HRPT stations, the station latitude is given on the web site. Station Longitude (4-byte real): for Station Name = "Wallops Flight Facility", -75.4753; for Station Name = "GSFC HRPT, NASA, MD", -76.8511; for all other HRPT stations, the station latitude is given on the web site. Mission (character): "SeaStar SeaWiFS".Mission Characteristics (character): "Nominal orbit: inclination = 98.2 (Sun-synchronous); node = 12 noon local (descending); eccentricity = <0.002; altitude = 705 km; ground speed = 6.75 km/sec". Sensor (character): "Sea-viewing Wide Field-of-view Sensor (SeaWiFS)". Sensor Characteristics (character): "Number of bands = 8; number of active bands = 8; wavelengths per band (nm) = 412, 443, 490, 510, 555, 670, 765, 865; bits per pixel = 10; instantaneous field-of-view = 1.5835 mrad; pixels per scan = 1285; scan rate = 6/sec; sample rate = 7710/sec". Note: Pixels per scan, scan rate, and sample rate are given for the sensor; effective rates for GAC data are lower due to subsampling. Data Type (character): "GAC", "LAC", "LUN", "SOL", "TDI", "IGC", or "HRPT". MLAC products also have a date type of HRPT. Replacement Flag (character): "ORIGINAL" if this is the first version of this product delivered to the DAAC; otherwise, it is set to the name of the product to be replaced (superseded) by the present product. Software ID (character): identifies version of the operational software used to create this product. Processing Time (character): local time of generation of this product; concatenated digits for year, day-of-year, hours, minutes, seconds, and fraction of seconds in the format of YYYYDDDHHMMSSFFF. Input Files (character): the name of the Level-0 file (without path) from which the current product was created. This information is stored in the product as part of its processing history. Processing Control (character): all input and processing control parameters used by the calling program to generate the product. Vertical bars or carriage return characters serve as parameter information delimiters. This information is stored in the product as part of its processing history. Processing Log (character): not used.

3.2 Data Time Start Time (character): start GMT of the first scan line of the scene; concatenated digits for year, day-of-year, hours, minutes, seconds, and fraction of seconds in the format of YYYYDDDHHMMSSFFF. End Time (character): start GMT of the last scan line of the scene; concatenated digits for year, day-of-year, hours, minutes, seconds, and fraction of seconds in the format of YYYYDDDHHMMSSFFF. Scene Center Time (character): start GMT of the center scan line of the scene; concatenateddigits for year, day-of-year, hours, minutes, seconds, and fraction of seconds in the format of YYYYDDDHHMMSSFFF. Node Crossing Time (character): GMT of descending node crossing; concatenated digits for year, day-of-year, hours, minutes, seconds, and fraction of seconds in the format of YYYYDDDHHMMSSFFF. Start Year (2-byte integer): GMT year of first scan line of the scene. Start Day

(2-byte integer): GMT day-of-year of first scan line of the scene. Start Millisec

(4-byte integer): GMT milliseconds-of-day of the first scan line of the scene. End Year (2-byte integer): GMT year of last scan line of the scene. End Day (2-byte integer): GMT day-of-year of last scan line of the scene. End Millisec

(4-byte integer): GMT milliseconds-of-day of the last scan line of the scene. Start Node (character): "Ascending" or "Descending"; describes node direction at the start of the scene. End Node (character): "Ascending" or "Descending"; describes node direction at the end of the scene. Orbit Number

(4-byte integer): orbit number of the scene. NORAD Line 1 (character): not used. NORAD Line 2 (character): not used.

3.3 Data Characteristics Pixels per Scan Line (4-byte integer): 248 if Data Type = "GAC", else, 1285. Number of Scan Lines (4-byte integer): number of scan lines in the scene. LAC Pixel Start Number (4-byte integer): the LAC pixel number corresponding to the first pixel in scan lines of this product; 147 if Data Type = "GAC", else, 1. LAC Pixel Subsampling (4-byte integer): the subsampling rate for the pixels in this product relative to LAC scan lines; 4 if Data Type = "GAC", else, 1. Scene Center Scan Line (4-byte integer): number of the center scan line (1-relative) of the scene, relative to first scan line. Filled Scan Lines

(4-byte integer): not used.FF Missing Frames (4-byte integer): frame formatter missing frames count for the Level-0 source file. SDPS Missing Frames (4-byte integer): not used.

3.4 File Metrics Gain 1 Saturated Pixels (4-byte integer, array size 8): number of saturated pixels for Earth gain 1 for each band. Gain 2 Saturated Pixels (4-byte integer, array size 8): number of saturated pixels for Earth gain 2 for each band. Gain 1 Non-Saturated Pixels (4-byte integer, array size 8): number of pixels not saturated for gain 1 for each band. Gain 2 Non-Saturated Pixels (4-byte integer, array size 8): number of pixels not saturated for gain 2 for each band. Zero Pixels (4-byte integer, array size 8): number of pixels, for each band, with value of 2 or less after subtraction of corresponding dark_rest

. Mean Gain 1 Radiance (4-byte real, array size 8): average radiance counts for pixels of gain 1 for each band. Mean Gain 2 Radiance (4-byte real, array size 8): average radiance counts for pixels of gain 2 for each band.

3.5 Scene Coordinates Latitude Units (character): "degrees North"; units used for all latitude values in this product. Longitude Units (character): "degrees East"; units used for all longitude values in this product. Scene Center Latitude (4-byte real): latitude of the nadir point of the scene's center scan line. Scene Center Longitude (4-byte real): longitude of the nadir point of the scene's center scan line. Scene Center Solar Zenith (4-byte real): solar zenith angle of the nadir point of the scene's center scan line. Upper Left Latitude (4-byte real): latitude of the upper left scene corner. Upper Left Longitude (4-byte real): longitude of the upper left scene corner. Upper Right Latitude (4-byte real): latitude of the upper right scene corner.Upper Right Longitude (4-byte real): longitude of the upper right scene corner.

Lower Left Latitude (4-byte real): latitude of the lower left scene corner. Lower Left Longitude (4-byte real): longitude of the lower left scene corner. Lower Right Latitude (4-byte real): latitude of the lower right scene corner. Lower Right Longitude (4-byte real): longitude of the lower right scene corner. Northernmost Latitude (4-byte real): northernmost latitude of all scan line end points. Southernmost Latitude (4-byte real): southernmost latitude of all scan line end points. Westernmost Longitude (4-byte real): westernmost longitude of all scan line end points. Easternmost Longitude (4-byte real): easternmost longitude of all scan line end points. Start Center Latitude (4-byte real): latitude of center pixel for first scan line. Start Center Longitude (4-byte real): longitude of center pixel for first scan line. End Center Latitude (4-byte real): latitude of center pixel for last scan line. End Center Longitude (4-byte real): longitude of center pixel for last scan line. Orbit Node Longitude (4-byte real): longitude of scene's orbit descending node (longitude at equatorial crossing of day-side node).

4 Data Objects Of the following six groups of data objects, four -- Scan-Line Attributes, Raw SeaStar Data, Converted Telemetry, and Navigation -- contain data that are functions of scan lines. That is, each data object within these groups has data for each scan line and is therefore dimensioned by the value of the global attribute, Number of Scan Lines

.
4.1 Scan-Line Attributes The following data objects are SDSs belonging to the Vgroup "Scan-Line Attributes". Attributes of the SDSs are shown in bold

.
msec (4-byte integer, array size Number of Scan Lines ): long_name = "Scan-line time, milliseconds of day"; valid_range = (0,86399999); units = "milliseconds". eng_qual (byte, array size Number of Scan Lines x 4): long_name = "Engineering data-outof-range flags"; set bits indicate instrument analog telemetry values out of range; see Table 1.s_flags (byte, array size Number of Scan Lines x 4): long_name = "Scan-line quality flags"; byte 1: sum of frame formatter bit error count and SDPS bit errors detected in this scan line; byte 2: corrupted telemetry flag; set if bit errors were detected for this scan line and this is the first minor frame (containing ACS and GPS telemetry) in the major frame; byte 3: for GAC data, the number (1 to 15) of the GAC line within the major frame; byte 4: number of synchronization bits used for the bit error count divided by 5; taken from the first two bytes of Level-0 record. s_satp (2-byte integer, array size Number of Scan Lines x 8): long_name = "Number of saturated pixels per band". s_zerop (2-byte integer, array size Number of Scan Lines x 8): long_name = "Number of zero pixels per band". slat (4-byte real, array size Number of Scan Lines ): long_name = "Scan start-pixel latitude"; valid_range = (-90.,90.). slon (4-byte real, array size Number of Scan Lines ): long_name = "Scan start-pixel longitude"; valid_range = (-180.,180.). clat (4-byte real, array size Number of Scan Lines ): long_name = "Scan center-pixel latitude"; valid_range = (-90.,90.). clon (4-byte real, array size Number of Scan Lines ): long_name = "Scan center-pixel longitude"; valid_range = (-180.,180.). elat (4-byte real, array size Number of Scan Lines ): long_name = "Scan end-pixel latitude"; valid_range = (-90.,90.). elon (4-byte real, array size Number of Scan Lines ): long_name = "Scan end-pixel longitude"; valid_range = (-180.,180.). csol_z (4-byte real, array size Number of Scan Lines ): long_name = "Scan center-pixel solar zenith angle"; valid_range = (0.,180.). tilt (4-byte real, array size Number of Scan Lines ): long_name = "Tilt angle for scan line"; valid_range = (-20.1,20.1); positive values indicate aft tilts and negative values indicate forward tilts; units = "degrees".

4.2 Raw SeaStar Data The following data objects are SDSs belonging to the Vgroup "Raw SeaStar Data". Attributes of the SDSs are shown in bold

. sc_id (2-byte integer, array size Number of Scan Lines x 2): long_name = "Spacecraft ID"; first word includes frame number; second word specifies data mode.sc_ttag (2-byte integer, array size Number of Scan Lines x 4): long_name = "Spacecraft time tag"; binary representation of spacecraft time. sc_soh (byte, array size Number of Scan Lines x 775): long_name = "Spacecraft state-ofhealth data"; raw state-of-health telemetry data. inst_tlm (2-byte integer, array size Number of Scan Lines x 44): long_name = "SeaWiFS instrument telemetry"; raw instrument and ancillary telemetry data, subcommutated depending on minor frame number and line number within frame. l1a_data (2-byte integer, array size Number of Scan Lines x Pixels per Scan Line x 8): long_name = "Level-1A data"; valid_range = (0,1023); units = "radiance counts"; dimensions are scan lines x pixels x bands. start_syn (2-byte integer, array size Number of Scan Lines x 8): long_name = "Start-synch pixel"; 8 synch words that indicate the start of the scan line. stop_syn (2-byte integer, array size Number of Scan Lines x 8): long_name = "Stop-synch pixel"; 8 synch words that indicate the end of the scan line. dark_rest (2-byte integer, array size Number of Scan Lines x 8): long_name = "Dark-restore pixel"; zero-level measurement (in counts) for each band taken from back side of scan. gain (2-byte integer, array size Number of Scan Lines x 8): long_name = "Band gain settings"; valid_range = (0,3); values are 0 = Earth gain 1, 1 = solar gain 2, 2 = Earth gain, 3 = lunar gain. tdi (2-byte integer, array size Number of Scan Lines x 8): long_name = "Band time-delay and integration settings"; valid_range = (0,255); detector combination used for each band.

4.3 Converted Telemetry The following data objects are SDSs belonging to the Vgroup "Converted Telemetry". Attributes of the SDSs are shown in bold

. inst_ana (4-byte real, array size Number of Scan Lines x 40): long_name = "Instrument analog telemetry"; 32 instrument analog telemetry data converted to physical units (last 8 word locations are spares); see Table 1. inst_dis (byte, array size Number of Scan Lines x 32): long_name = "Instrument discrete telemetry"; 24 instrument discrete telemetry data, unpacked 1 bit per byte (last 8 byte locations are spares); see Table 2.
sc_ana (4-byte real, array size Number of Scan Lines x 40): long_name = "Spacecraft analog telemetry"; selected spacecraft analog telemetry data converted to physical units (last 2 word locations are spares); see Table 3. sc_dis (byte, array size Number of Scan Lines x 40): long_name = "Spacecraft discretetelemetry"; selected spacecraft discrete telemetry data; see Table 4.

scan_temp (2-byte integer, array size Number of Scan Lines x 8): long_name = "Detector temperature counts"; valid_range = (0,255); digitized scan temperature for each band. side (2-byte integer, array size Number of Scan Lines ): long_name = "Mirror side for scan line"; valid_range = (0,1). 4.4 Navigation The following data objects are SDSs belonging to the Vgroup "Navigation". Attributes of the SDSs are shown in bold . See the SeaWiFS Postlaunch Technical Report Series , volume 16 for a description of methods used for the operational navigation of SeaWiFS data. orb_vec (4-byte real, array size Number of Scan Lines x 3): long_name = "Orbit position vector at scan line time"; orbit position vector interpolated to the time of the scan line; valid_range = (-7200.,7200.); units = "kilometers"; used to determine spacecraft position for geolocation. l_vert (4-byte real, array size Number of Scan Lines x 3): long_name = "Local vertical vector in ECEF frame"; local vertical (geodedic) vector at the spacecraft position, in the ECEF frame; valid_range = (-1.,1.); used to determine roll and pitch of spacecraft. sun_ref (4-byte real, array size Number of Scan Lines x 3): long_name = "Reference Sun vector in ECEF frame"; unit Sun vector in the Earth-cetered, Earth-fixed (ECEF) frame; valid_range = (-1.,1.); used for computing solar zenith and azimuth angles. att_ang (4-byte real, array size Number of Scan Lines x 3): long_name = "Computed yaw, roll, pitch"; valid_range = (-180.,180.); relates spacecraft position to orbit reference frame. sen_mat (4-byte real, array size Number of Scan Lines x 3 x 3): long_name = "ECEF-tosensor-frame matrix"; valid_range = (-1.,1.); relates sensor scan plane to Earth-fixed reference frame (3x3 matrix, in column-major order). scan_ell (4-byte real, array size Number of Scan Lines x 6): long_name = "Scan-track ellipse coefficients"; defines scan-track geometry in sensor frame. nflag (4-byte integer, array size Number of Scan Lines x 8): long_name = "Navigation flags"; in the 8-integer array, the integers represent, respectively: navigation failure flag; orbit flag; Sun sensor flag; Earth sensor flag; spacecraft attitude uncertainty flag; time code flag; tilt data flag; and navigation warning flag. All flags may have the value 0 for valid or 1 for invalid. The tilt data flag only may also have the value of 2 to indicate a changing tilt. Note that the failure flag is only to 1 if the orbit flag, time code flag or tilt data flag are set to 1.

4.5 Sensor TiltThe following data objects are SDSes belonging to the Vgroup "Sensor Tilt". Attributes of the

SDSs are shown in bold

. ntilts (4-byte integer): long_name = "Number of scene tilt states". tilt_flags (2-byte integer, array size 20): long_name = "Tilt indicators"; valid_range = (-1,3); tilt flags corresponding to each tilt state in the scene; possible values are 0 for nadir tilt, 1 for forward tilt, 2 for aft tilt, and 3 to indicate a changing tilt angle; -1 indicates an unknown state; contains ntilts valid values. tilt_ranges

(2-byte integer, array size 20 x 2): long_name = "Scan-line number ranges of scene tilt states"; first and last scan line numbers (1-relative) corresponding to each tilt state in the scene; contains ntilts valid values. tilt_lats (4-byte real, array size 20 x 2 x 2): long_name = "Latitudes of tilt-range scan line end points"; valid_range = (-90.,90.); latitudes of the end pixels for the scan lines of tilt_ranges

(dimensions are ntilts x first/last scans x start/end pixels); contains ntilts valid values. tilt_lons (4-byte real, array size 20 x 2 x 2): long_name = "Longitudes of tilt-range scan line end points"; valid_range = (-180.,180.); longitudes of the end pixels for the scan lines of tilt_ranges

(dimensions are ntilts x first/last scans x start/end pixels); contains ntilts valid values.

4.6 Calibration The following data objects are SDSes belonging to the Vgroup "Calibration". These fields are no longer filled in the Level-1A product, but are retained for historical reasons. entry_year (2-byte integer): long_name = "Calibration entry year"; the year (4 digits) that the entry used for this Vgroup's data was made in the sensor calibration table. entry_day

(2-byte integer): long_name = "Calibration entry day-of-year"; the day-of-year that the entry used for this Vgroup's data was made in the sensor calibration table. ref_year (2-byte integer): long_name = "Calibration reference year"; 1997; the year of the calibration reference time. ref_day (2-byte integer): long_name = "Calibration reference day-of-year"; 64; the day of year of the calibration reference time. ref_minute (2-byte integer): long_name = "Calibration reference minute-of-day"; 720; the minute of day of the calibration reference time. mirror (4-byte real, array size 2 x 8): long_name = "Mirror-side correction factors"; mirror side-0 and -1 correction factors for calibration of the eight bands (dimensions are sides x bands).t_const (8-byte real, array size 8): long_name = "Time-dependent correction constant terms"; time-dependent correction constant terms for all bands. t_linear (8-byte real, array size 8): long_name = "Time-dependent correction linear coefficients"; time-dependent correction linear coefficients for all bands. t_quadratic (8-byte real, array size 8): long_name = "Time-dependent correction quadratic coefficients"; time-dependent correction quadratic coefficients for all bands. cal_offs (4-byte real, array size 8): long_name = "Calibration system offsets"; calibration system offsets for all bands. counts (4-byte real, array size 8 x 4 x 5): long_name = "Digital counts of calibration knees"; valid_range = (0,1023); digital counts (zero-offsets corrected) corresponding to each calibration knee for all gains and bands (dimensions are bands x gains x knees). rads (4-byte real, array size 8 x 4 x 5): long_name = "Radiances of calibration knees"; radiances corresponding to each calibration knee for all gains and bands (dimensions are bands x gains x knees).

Table 1. Converted instrument analog telemetry in inst_ana

.
Array Indices Description Units 1 - 4 Focal plan assembly temperatures degrees C 5 Telescope motor temperature degrees C 6 - 7 Tilt base and platform temperatures degrees C 8 Half angle motor temperature degress C 9 - 10 Power supply input current (A and B sides) amps 11 - 12 Analog power voltage (+15V and -15V) volts 13 5V logical power voltage volts 14 Power supply temperature degrees C 15 B1/B2 postamp temperature degrees C 16 Servo drive temperature degrees C 17 - 20 Servo power voltage (+30V, +21V, -21V, +5V) volts 21 Angular momentum compensator speed rpm 22 - 23 Tilt motor positions (platform and base) degrees24 28V heater power volts

25 - 26 Telescope motor current (A and B sides) amps 27 - 28 Half angle motor current (A and B sides) amps 29 - 30 Servo phase error (A and B sides) millirad 31 - 32 Angular momentum compensator motor current (A and B) amps 33 - 40 SparesTable 2. Converted instrument discrete telemetry in inst_dis

.

Array index Description and convention 1 Servo selected (1 = A) 2 Angular momentum compensator on (1 = on) 3 Servo A locked (1 = true) 4 Servo B locked (1 = true) 5 Timing selected (1 = A) 6 Tilt A selected (1 = true) 7 Tilt B selected (1 = true) 8 Tilt telemetry on (1 = on) 9 Stow on (1 = on) 10 Stow aligned (1 = on) 11 Heaters status (1 = enabled) 12 Solar door open (1 = open) 13 Analog power on (1 = on) 14 Tilt platform limit (1 = true) 15 Tilt base limit (1 = true) 16 Tilt nadir aligned (1 = true) 17 Tilt aft aligned (1 = true) 18 Tilt forward aligned (1 = true) 19 Earth mode data on (1 = Earth mode, 0 = solar mode) 20 Half angle mirror side (1 = side 2) 21 Image data sync (1 = true) 22 Angular momentum compensator at speed (1 = true) 23-32 SparesTable 3. Converted spacecraft analog telemetry in sc_ana
.

Array Indices Description Units 1 - 3 GPS orbit position vector (ECEF frame) km 4 - 6 GPS orbit velocity vector (ECEF frame) km/sec 7-9 ACS attitude angles yaw, roll, pitch degrees 10 - 11 Digital Sun sensor A outputs n/a 12 - 13 Digital Sun sensor B outputs n/a 14 - 15 Digital Sun sensor C outputs n/a 16 - 17 Horizon sensor A angles (phase and chord) degrees 18 - 19 Horizon sensor B angles (phase and chord) degrees 20 GPS dilution-of-precision n/a 21 GPS time-tag fractional second second 22 Momentum wheel 1 speed rpm 23 Momentum wheel 1 current amp 24 Momentum wheel 2 speed rpm 25 Momentum wheel 2 current amp 26 - 28 Torquer 1 commanded levels (x, y, z) amp-m^2 29 - 31 Torquer 1 commanded levels (x, y, z) amp-m^2 32 - 35 Magnetometer 1 field values (x,y,z,r) nanotesla 36 - 38 Attitude angle rates (yaw, roll, pitch) degree/sec 39 - 40 sparesTable 4. Converted spacecraft discrete telemetry in sc_dis

.

Array Indices Description 1 - 3 DSS Sun presence flags (A, B, C) 4 - 6 DSS status (A, B, C) 7 - 8 HS A status 9 - 10 HS B status 11 Number of GPS satellites visible 12 Number of GPS sateliites tracked 13 GPS receiver status 14 - 15 GPS time tag year 16 GPS time tag month 17 GPS time tag day 18 - 20 GPS time tag hour, minute, second 21 - 24 DSS A time tag (milliseconds of week) 25 - 28 DSS B time tag (milliseconds of week) 29 - 32 DSS C time tag (milliseconds of week) 33 - 36 HS A time tag (milliseconds of week) 37 - 40 HS B time tag (milliseconds of week)

## OCEAN DISCIPLINE PROCESSING SYSTEM (ODPS) LAND/WATER MASK FORMAT

1. 0 Summary Description The Ocean Discipline Processing System requires a land/water mask file as input for Level 2 processing. The mask is used to set the land mask flag for each pixel. The file is in binary format, and integers are big-endian. The mask file was originally generated in 1993 based on the World Vector Shoreline (WVS) database. This database did not include any inland waterways, and so these areas were all flagged as land. In October 1997, shortly after the SeaWiFS launch, the file was modified to include inland waterways, based on the World Data Bank (WDB). The land-water determination is based on the grid point center. The format was designed to be highly compact, with full-resolution land-water mask values stored only for those regions which contain both. Each mask point requires a single bit, so a 16- bit integer stores 16 points. The file requires software in order to be unpacked and interpreted. The original design was general enough to allow for different resolutions and geographic limits. The file has been built at one resolution, and with global extent, as indicated below. 2.0 Detailed Format Specifications The file format is based on fixed-length records. This allows FORTRAN direct data access, so that the records can be read out of order. The file structure is specified in the header record. The remainder of the file consists of an array of pointers, which are based on 1x1 degree latitude/longitude bins, followed by individual mask records for those bins containing both land and water. 2.1 File Header The header specifies the overall structure of the file. The values in this record were intended to be variable in order to allow for different resolutions and geographic limits. Only one structure has actually been implemented, with the values specified here. The resolution of 128 points per degree corresponds to about 0.9 km in longitude at the equator, and in latitude. Type Size Value Description short 1 128 Mask resolution (grid points per degree of latitude or longitude). short 1 9644 Number of fixed-length records in the file. short 1 2048 Record length (bytes). short 1 -180 Western boundary (degrees longitude). short 1 180 Eastern boundary (degrees longitude). short 1 -90 Southern boundary (degrees latitude). short 1 90 Northern boundary (degrees latitude). short 1017 0 Fill (for 2048-byte record).

### 2.2 Record Pointers

The file pointer records contain one pointer for each 1x1 degree latitude/longitude bin. Thus this is represented as a rectangular array, which spans 64 actual records. The pointers are used to indicate whether the bin is water, land, or both. The pointers are ordered with longitude varying more rapidly; order is West-to-East in longitude, and South-to-North in latitude. Type Size Description short 360 x 180 Land/water mask pointers:

= 0, bin is all water; = 1, bin is all land; > 1, mask record number in file (0-base). short 736 Fill (for 2048-byte records) .

2.2 Land Mask Records Each land mask record contains a bit mask for the NxN grid of points within a 1-degree bin. The mask is compressed to 16 mask values per 2-byte integer. For the implemented mask file, each bin contains a 128x128 grid, with 16384 mask bits; this is packed into 1024 words. The order is the same as the for the pointer array (longitude varies more rapidly, from Southwest to Northeast). Type Size Description
s h ort 1024 Land/water mask (16384 mask bits packed 16 per word);

= 0, point is water; = 1, point is land.

## Ocean Level - 2 Data Products March 22, 2010

1.0 Introduction This document describes th e specifications of Ocean Level

- 2 archive products that are produced and distributed by the NASA Goddard Space Flight Center's Ocean Data Processing System (ODPS). T he products are implemented in the Hierarchical Data Format (HDF), and HDF terminology is used in this document. These specifications are given in terms of the logical implementation of the products in HDF and are not a physical description of file conten ts. Therefore, HDF software must be used to create or read these products. A Level

- 2 data product is generated from either a Level

- 1A (SeaWiFS, OCTS or CZCS) or Level 1B (MODIS or MERIS ) product. The main data contents of the product are the geophysica l values for each pixel, derived from the Level

- 1 radiance by applying the sensor calibration (for Level

- 1A), atmospheric corrections, and geophysical parameter algorithms. Each Level

- 2 product corresponds exactly in geographical coverage (scan

- line and pixel extent) to that of its parent Level

- 1 product and is stored in one physical HDF file. Note that a number of fields were originally specified for the SeaWiFS data products and are not applicable to the other sensor products; these are indicated as Sea WiFS only.

2.0 Naming Convention The form of a Level

- 2 file name is iyyyydddhhmmss.L2_rrr_ppp, where i is the instrument identifier (S for SeaWiFS, A for Aqua MODIS, T is for Terra MODIS, O for OCTS , C is for CZCS, M is for MERIS ), yyyydddhhmmss are t he UTC year, day of the year, hours, minutes, and seconds of the first scan li ne, rrr is the resolution, and ppp is the product identifier (OC for ocean c olor or SST for sea surface t emperature. The resolution can be: GAC for Global Area Coverage (i.e. , subsampled image data, for SeaWiFS or OCTS) LAC for Local Area Coverage (full

- resolution, 1 km SeaWiFS, MODIS, OCTS or CZCS) Hxxx for SeaWiFS HRPT direct

- broadcast (where xxx is a station identifier, e.g., HNSG for the NASA SeaWiFS station) MLAC for merg ed LAC (multiple scenes from a single orbit merged into a single product). Examples of Level

- 2 file names are: S1998001180514.L2_GAC _OC SeaWiFS GAC (4 km subsampled) ocean color A2004032163500.L2_LAC _OC Aqua MODIS LAC (1 km) ocean color T2006022172000.L2 _LAC_SST Terra MODIS 1 km SST O1997001130032.L2_GAC OCTS GAC (4 km subsampled)

### 3.0 Global Attributes For global attributes that have constant values specific to this product type, the actual value is given.

3.1 Mission and Documentation This sec tion lists attributes that are common to all sensors, followed by sensor

- specific attributes. 3.1.1 Common Attributes Product Name (character): the name of the product file (without path). Title (character): data product type, e.g., "SeaWiFS Level

- 2 Da ta”. Sensor Name (character): name of sensor, e.g., “MODISA”” Replacement Flag (character): "ORIGINAL" if this is the first version of this product delivered to the DAAC; otherwise, it is set to the name of the product to be replaced (superseded) by the present product. Software Name (character): "l2gen "; name of the software used to create this product. Software Version (character): version of the software used to create this product. Processing Time (character): UTC of generation of this product; co ncatenated digits for year, day

- of

- year, hours, minutes, seconds, and fraction of seconds in the format of YYYYDDDHHMMSSFFF. Processing Control (character): path and name of the file containing the control parameters. This information is simply stored in the product as part of its processing history. Input Parameters (character): all input and processing control parameters used by the calling program to generate the product. Vertical bars or carriage return characters serve as parameter information deli miters. This information is simply stored in the product as part of its processing history. Input Files (character): the names of the Level

- 1A or Level

- 1B file (without path; always listed first) from which the current product was created and of the anci llary (environmental) data files (without paths, each separated by one comma) used in the processing. This information is simply stored in the product as part of its processing history. Calibration Data (character): the names of the calibration files (w ithout paths, each separated by one comma) used in the processing. This information is simply stored in the product as part of its processing history.

### 3.1.2 SeaWiFS - Specific Attributes Data Center (character): "NASA/GSFC SeaWiFS Data Processing Cent er". Station Name (character): "Wallops Flight Facility". Station Latitude (4

- byte real): 37.9272. Station Longitude (4

- byte real):

- 75.4753. Mission (character): "SeaStar SeaWiFS". Mission Characteristics (character): "Nominal orbit: inclination = 98.2 (Sun

- synchronous); node = 12 noon local (descending); eccentricity = <0.002; altitude = 705 km; ground speed = 6.75 km/sec". Sensor (character): "Sea

- viewing Wide Field

- of

- view Sensor (SeaWiFS)". Sensor Characteristics (character): "Number of bands = 8; number of active bands = 8; wavelengths per band (nm) = 412, 443, 490, 510, 555, 670, 765, 865; bits per pixel = 10; instantaneous field

- of

- view = 1.5835 mrad; pixels per scan = 1285; scan rate = 6/sec; sample rate = 7710/sec". Data Type (character): " GAC".

3.2 Data Time Start Time (character): start UTC of the first scan line of the scene; concatenated digits for year, day

- of

- year, hours, minutes, seconds, and fraction of seconds in the format of YYYYDDDHHMMSSFFF. End Time (character): start UTC of the last scan line of the scene; concatenated digits for year, day

- of

- year, hours, minutes, seconds, and fraction of seconds in the format of YYYYDDDHHMMSSFFF. Scene Center Time (character): start UTC of the center scan line of the scene; concatenated d igits for year, day

- of

- year, hours, minutes, seconds, and fraction of seconds in the format of YYYYDDDHHMMSSFFF. Node Crossing Time (character): UTC of descending node crossing; concatenated digits for year, day

- of

- year, hours, minutes, seconds, and fract ion of seconds in the format of YYYYDDDHHMMSSFFF (SeaWiFS only). Start Year (2

- byte integer): UTC year of first scan line of the scene. Start Day (2

- byte integer): UTC day

- of

- year of first scan line of the scene. Start Millisec (4

- byte integer): UTC mil liseconds

- of

- day of start of the first scan line of the scene.

### End Year (2

- byte integer): UTC year of last scan line of the scene. End Day (2

- byte integer): UTC day

- of

- year of last scan line of the scene. End Millisec (4

- byte integer): UTC milliseconds

- of

- day of start of the last scan line of the scene. Start Node (character): "Ascending" or "Descending"; describes node direction at the start of the scene. End Node (character): "Ascending" or "Descending"; describes node direction at the end of the sce ne. Orbit Number (4

- byte integer): orbit number of the scene (SeaWiFS only). 3.3 Data Structure Pixels per Scan Line (4

- byte integer): number of pixels in each scan line. Number of Scan Lines (4

- byte integer): number of scan lines in the scene. Numbe r of Bands (4

- byte integer): 8; number of channels/wavelengths. LAC Pixel Start Number (4

- byte integer): the LAC pixel number corresponding to the first pixel in scan lines of this product (SeaWiFS only). LAC Pixel Subsampling (4

- byte integer): the subsampling rate for the pixels in this product relative to LAC scan lines (SeaWiFS only). Scene Center Scan Line (4

- byte integer): number of the center scan line (1

- relative) of the scene, relative to first scan line. Number of Scan Control Points (4

- byte integer): number of rows in the latitude and longitude control point arrays. Number of Pixel Control Points (4

- byte integer): number of columns in the latitude and longitude control point arrays. Mask Names (character): list of algorithm names (each separ ated by one comma, from the values of the attributes f01_name to f32_name of the l2_flags SDS in the Geophysical Data Vgroup) for the flag bits that were used as masks when generating this product. Flag Percentages (4

- byte real, array size 32): percentages of pixels in the scene for which a bit in l2_flags is set; each of the 32 values corresponds to one of the 32 bits (from lowest to highest) in l2_flags

.

### 3.4 Scene Coordinates Latitude Units (character): "degrees North"; units used for all latitude values in this product. Longitude Units (character): "degrees East"; units used for all longitude values in this product. Scene Center Latitude (4

- byte real): latitude of the midpoint of the scene center scan line. Scene Center Longitude (4

- byte real): longitude of the midpoint of the scene center scan line. Scene Center Solar Zenith (4

- byte real): solar zenith angle at the scene center. Upper Left Latitude (4

- byte real): latitude of the upper left scene corner. Upper Left Longitude (4

- byte real): longitude of the upper left scene corner. Upper Right Latitude (4

- byte real): latitude of the upper right scene corner. Upper Right Longitude (4

- byte real): longitude of the upper right scene corner. Lower Left Latitude (4

- byte real): latitude of the lower left scene corner. Lower Left Longitude (4

- byte real): longitude of the lower left scene corner. Lower Right Latitude (4

- byte real): latitude of the lower right scene corner. Lower Right Longitude (4

- byte real): longitude of the lower right scene corne r. Northernmost Latitude (4

- byte real): northernmost latitude of all scan line end points. Southernmost Latitude (4

- byte real): southernmost latitude of all scan line end points. Westernmost Longitude (4

- byte real): westernmost longitude of all scan line end points. Easternmost Longitude (4

- byte real): easternmost longitude of all scan line end points. Start Center Latitude (4

- byte real): latitude of center pixel for first scan line. Start Center Longitude (4

- byte real): longitude of center pixel for first scan line. End Center Latitude (4

- byte real): latitude of center pixel for last scan line. End Center Longitude (4

- byte real): longitude of center pixel for last scan line. Orbit Node Longitude (4

- byte real): longitude of scene's orbit descending node (longitude at equatorial crossing of day

- side node) (SeaWiFS only). Earth - Sun Distance Correction (4

- byte real): correction applied to radiance for irradiance changes caused by the annual Earth

- Sun distance variation, computed as the square of the in verse of the distance in astronomical units.

### 4.0 Data Objects Of the following data object groups, three (Scan

- Line Attributes, Geophysical Data, and Navigation) contain data that are functions of scan lines. That is, each data object within these groups have data for each scan line and is therefore dimensioned by the value of the global attribute, Number of Scan Lines . Thus, to get all the data corresponding to a specific scan line, n, the n th 

### values of all data objects in these four groups would nee d to be read.

4.1 Scan - Line Attributes The following data objects are SDS s belonging to the Vgroup "Scan

- Line Attributes". Attributes of the SDSs are shown in bold

. year (4

- byte integer, array size Number of Scan Lines ): long_name = "Scan year"; vali d_range = (1996, 2038); units = "years". day (4

- byte integer, array size Number of Scan Lines ): long_name = "Scan day of year; valid_range = (1,366); units = "days".
msec (4

- byte integer, array size Number of Scan Lines ): long_name = "Scan

- line time, mil liseconds of day"; valid_range = (0,86399999), units = "milliseconds". slat (4

- byte real, array size Number of Scan Lines ): long_name = "Scan start

- pixel latitude"; valid_range = (

- 90.,90.); units = "degrees". slon (4

- byte real, array size Number of Scan Lines ): long_name = "Scan start

- pixel longitude"; valid_range = (

- 180.,180.); units = "degrees". clat (4

- byte real, array size Number of Scan Lines ): long_name = "Scan center

- pixel latitude"; valid_range = (

- 90.,90.); units = "degrees". clon (4

- byte rea l, array size Number of Scan Lines ): long_name = "Scan center

- pixel longitude"; valid_range = (

- 180.,180.); units = "degrees". elat (4

- byte real, array size Number of Scan Lines ): long_name = "Scan end

- pixel latitude"; valid_range = (

- 90.,90.); units = "d egrees". elon (4

- byte real, array size Number of Scan Lines ): long_name = "Scan end

- pixel longitude"; valid_range = (

- 180.,180.); units = "degrees". csol_z (4

- byte real, array size Number of Scan Lines ): long_name = "Scan center

- pixel solar zenith angle" ; valid_range = (0.,180.); units = "degrees".

### 4.2 Geophysical Data 4.2.1 Retrieved Geophysical Parameters The retrieved geophysical parameters are stored in SDSs belonging to the Vgroup "Geophysical Data". A list of parameters included in the archive pr oducts is shown in Table 1, along with the values of the standard attributes: long_name , slope , intercept , units . All parameter SDSs have dimensions Number of Scan Lines x Pixels per Scan Line . Most parameters are stored as integers, which are scaled according to the attributes slope and i ntercept attached to each SDS. In addition, each parameter has attributes bad_value_scaled and bad_value_unscaled , which indicate the values stored for pixels in which the parameter could not be computed; for scaled int egers, the former specifies the actual value stored and the latter, the equivalent parameter value. Parameters that are wavelength

- specific (e.g., water

- leaving radiance) have separate SDSs for each band used to derive the parameter; a list of wavelengths for each sensor is given in Table 2. This section lists those parameters that are stored in the standard archive products. The SST and SST4 are stored in separate archive products with their respective quality fields. A complete list of parameters that can be output by the software is given in the L2gen User Guide.

Table 1. Summary of Level

- 2 geophysical parameters and attributes
Parameter Storage (bytes) Approximate Range Units Long Name

Rrs _WWW 2

- 0.015

– 0.115 sr - 1 

### Remote sensing reflectance at WWW nm chlor_a 4 0

– 100 mg m - 3 

### Chlorophyll Concentration, OC4 Algorithm K d _490 2 0

– 6.4 m - 1 

### Diffuse attenuation coefficient at 490 nm aot _WWW 2 0

– 3.2 none Aerosol optical thickness at WWW nm angstrom 2

- 0.7

– 5.7 n one Angstrom coefficient, 443 to 865 nm pic 2 0

– 0.13 mol m - 3 

### Calcite Concentration

poc 2 0

– 12,800 mg m - 3 

### Particulate Organic Carbon
cdom_index 2 0

– 12.8 None CDOM Index

### par 2 0

– 131 Einsteins m - 2 

### day - 1 

### Photosynthetical ly Available Radiation ipar 2 0

– 131 Einsteins m - 2 

### sec - 1 

### Instantaneous Photosynthetically Available Radiation nflh 2 0

– 131 mW m - 2 

### μm - 1 

### sr - 1 

### Normalized Fluorescence Line Height sst 2

- 2

– 45 degrees C Sea Surface Temperature

sst4 2

- 2

– 45 degrees C 4um Sea Surface Temperature

Table 2. Band

- center wavelengths by sensor (nm). These are used in the geophysical parameter names that are based on wavelength.
SeaWiFS MODIS OCTS CZCS MERIS 412 (1) 412 (1) 412 (1) 413 (1) 443 (1) 443 (1) 443 (1) 443 (1) 443 (1) 469 (1),(3) 490 (1) 488 (1) 490 (1) 490 (1) 510 (1) 531 (1) 520 (1) 52 0 (1) 510 (1) 555 (1) 547 (1) 565 (1) 550 (1) 560 (1) 555 (1),(3) 645 (1),(3) 620 (1) 670 (1) 667 (1) 670 (1) 670 (1),(2) 665 (1) 678 (1) 681 (1) 765 748 765 750 754 865 (2) 869 (2) 865 (2) 865 (2) (1) Use d for Rrs _WWW (2) Used for aot_WWW (3) Generated from MODIS 250m or 500m data aggregated to 1 km

### 4.2.2 Flags and Quality Levels l2_flags (4

- byte integer, array size Number of Scan Lines x Pixels per Scan Line ): long_name = "Level

- 2 Processing Flags"; units = "dimensionless"; 32 bilevel flags in four bytes used as indicators of certain conditions (see Table 3). This SDS has attributes f01_name , ... f32_name that provide the names of the algorithms (also listed in Table 3) used in determining the setting of the corresponding bits in l2_flags (the least significant bit being the first bit). The algorithms associated with these names, and the use of the corresponding bits as masks or as flags, are described in volumes of the SeaWiFS TM Series. Note that fo r SST, only the LAND, SSTWARN and SSTFAIL flags are meaningful, as the quality indicators are stored in sst_qual and sst4_qual, respectively.
Table 3. Conditions indicated for the pixel associated with the setting of individual bits in l 2_flags . These correspond to the algorithm names given by the attributes of l2_flags

. Bit Set = 1 Condition Indicated Algorithm Name 1 atmospheric correction failure from invalid inputs ATMFAIL 2 land LAND 3 questionable value for one or more parameters PRODWARN 4 severe Sun glint HIGLINT 5 total radiance above knee in any band HILT 6 satellite zenith angle above limit HISATZEN 7 shallow water COASTZ 8 not used SPARE 9 stray light contamination STRAYLIGHT 10 clouds and/or ice CLDICE 11 coccolithophore COCCOLITH 12 turbid, case

- 2 water TURBIDW 13 solar zenith angle above limit HISOLZEN 14 not used SPARE 15 low water

- leaving radiance at 555 nm LOWLW 16 chlorophyll not calculable CHLFAIL 17 questionable navigation (e.g, tilt change) NAVWARN 18 absorbing aerosol index above threshold ABSAER 19 not used SPARE 20 maximum iterations of NIR algorithm MAXAERITER 21 moderate Sun glint MODGLINT

### 22 chlorophyll out of range CHLWARN 23 epsil on out of range ATMWARN 24 not used SPARE 25 sea ice in pixel (based on climatology) SEAICE 26 navigation failure condition indicated in nav flags NAVFAIL 27 insufficient valid neighboring pixels for epsilon filtering FILTER 28 sea surf ace temperature warning flag (MODIS only) SSTWARN 29 sea surface temperature failure flag (MODIS only) SSTFAIL 30 degree of polarization above limit (MODIS only) HIPOL 31 one or more parameters could not be computed PRODFAIL 32 not used SP ARE
qual_sst (SST product only) (byte, array size Number of Scan Lines x Pixels per Scan Line ): long_name = "Quality Levels, Sea Surface Temperature"; units = "dimensionless"; byte array indicating SST quality with range of 0 (best) to 3 (invalid); used during generation of binned products to select best available data for a bin; specific quality levels are documented in TBD. qual_sst4 (SST4 product only) (byte, array size Number of Scan Lines x Pixels per Scan Line ): long_name = "Quality Levels, Sea Su rface Temperature"; units = "dimensionless"; byte array indicating SST4 quality with range of 0 (best) to 3 (invalid); used during generation of binned products to select best available data for a bin; specific quality levels are documented in TBD. 4.3 Naviga tion 4.3.1 Navigation Control Points and Tilt The following data objects are SDS s belonging to the Vgroup "Navigation". Attributes of the SDSs are shown in bold . The control point arrays latitude and longitude are used for Level

- 3 processing and display. The most accurate geolocation will be obtained for SeaWiFS using the navigation block fields with the SeaWiFS Project software (see 4.4.4, below), and for MODIS using the Geolocation product. cntl_pt_cols (4

- byte integer, array size Number of Pixel C ontrol Points ): long_name = "Pixel control points"; units = "none"; array of pixel indices corresponding to latitude and longitude SDSs. cntl_pt_rows (4

- byte integer, array size Number of Scan Control Points ): long_name = "Scan control points"; units = "none"; array of scan line indices corresponding to latitude and longitude SDSs. longitude (4

- byte real, array size Number of Scan Control Points x Number of Pixel Control Points ): long_name = "Longitudes at control points"; units = "degrees"; valid_range =

### "- 180., 180."; units = "degrees"; longitudes of pixels indicated by cntl_pt_cols and cntl_pt_rows

. latitude (4

- byte real, array size Number of Scan Control Points x Number of Pixel Control Points ): long_name = "Latitudes at control poi nts"; units = "degrees"; valid_range = "

- 90., 90."; units = "degrees"; latitudes of pixels indicated by cntl_pt_cols and cntl_pt_rows

. tilt (4

- byte real, array size Number of Scan Lines ): long_name = "Tilt angle for scan line"; valid_range = (

- 20.1,20.1); units = "degrees"; positive values indicate aft tilts and negative values indicate forward tilts. 4.3.2 SeaWiFS Navigation Block (SeaWiFS only) The following data objects are additional SDS s belonging to the Vgroup "Navigation" in SeaWiFS data produc ts. Attributes of the SDSs are shown in bold . See the SeaWiFS Postlaunch Technical Report Series , volume 16 for a description of methods used for the operational navigation of SeaWiFS data. orb_vec (4

- byte real, array size Number of Scan Lines x 3): lon g_name = "Orbit position vector at scan line time"; orbit position vector interpolated to the time of the scan line; valid_range = (

- 7200.,7200.); units = "kilometers"; used to determine spacecraft position for geolocation. sun_ref (4

- byte real, array size Number of Scan Lines x 3): long_name = "Reference Sun vector in ECEF frame"; unit Sun vector in the Earth

- centered , Earth

- fixed (ECEF) frame; valid_range = (

- 1.,1.); used for computing solar zenith and azimuth angles. att_ang (4

- byte real, array size Nu mber of Scan Lines x 3): long_name = "Computed yaw, roll, pitch"; valid_range = (

- 180.,180.); relates spacecraft position to orbit reference frame. sen_mat (4

- byte real, array size Number of Scan Lines x 3 x 3): long_name = "ECEF

- to
sensor - frame matrix"; v alid_range = (

- 1.,1.); relates sensor scan plane to Earth

- fixed reference frame (3x3 matrix, in column

- major order). scan_ell (4

- byte real, array size Number of Scan Lines x 6): long_name = "Scan

- track ellipse coefficients"; defines scan

- track geometry in sensor frame. nflag (4

- byte integer, array size Number of Scan Lines x 8): long_name = "Navigation flags"; in the 8

- integer array, the integers represent, respectively: navigation failure flag; orbit flag; Sun sensor flag; Earth sensor flag; spacecraft attitude uncertainty flag; time code flag; tilt data flag; and navigation warning flag. All flags may have the value 0 for valid or 1 for invalid. The tilt data flag only may also have the value of 2 to indicate a changing tilt. Note that the failure fla g is only to 1 if the orbit flag, time code flag or tilt data flag are set to 1. 4.4 Sensor Tilt (SeaWiFS only) The following data objects are SDS s belonging to the Vgroup "Sensor Tilt" in the SeaWiFS data products. Attributes of the SDSs are shown in bold

.

### ntilts (4

- byte integer): long_name = "Number of scene tilt states". tilt_flags (2

- byte integer, array size 20): long_name = "Tilt indicators"; valid_range = (

- 1,3); tilt flags corresponding to each tilt state in the scene; possible values are 0 fo r nadir tilt, 1 for forward tilt, 2 for aft tilt, and 3 to indicate a changing tilt angle;

- 1 indicates an unknown state; contains ntilts valid values. tilt_ranges (2

- byte integer, array size 20 x 2): long_name = "Scan

- line number ranges of scene tilt sta tes"; first and last scan line numbers (1

- relative) corresponding to each tilt state in the scene; contains ntilts valid values.

4.5 Sensor Band Parameters The following data objects are SDS s belonging to the Vgroup "Sensor Band Parameters". Attribute s of the SDSs are shown in bold . These parameters are used in the Level 2 processing. wavelength (4

- byte integer, array size Number of Bands ); long_name = "Wavelengths"; units = "nm"; band center wavelength for each band. vcal_gain (4

- byte real, array s ize Number of Bands ); long_name = "Vicarious Calibration Gain"; units = "dimensionless"; vicarious calibration gain for each band. vcal_offset (4

- byte real, array size Number of Bands ); long_name = "Vicarious Calibration Offset"; units = "mW cm^

- 2 um^

- 1 s r^

- 1"; vicarious calibration offset for each band. F0 (4

- byte real, array size Number of Bands ); long_name = "Mean Solar Flux"; units = "mW cm^

- 2 um^

- 1 sr^

- 1"; mean solar flux for each band. k_oz (4

- byte real, array size Number of Bands ); long_name = "Ozone Absorption Coefficient"; units = "cm^

- 1"; ozone absorption coefficient for each band. Tau_r (4

- byte real, array size Number of Bands ); long_name = "Rayleigh Optical Thickness";

units = "dimensionless"; Rayleigh optical thickness for each band.

##  



 
	












 






 


!
"#


	$"#%&



	
	


'

"
	$'"%('"

	
	
&







	
	
	


'"





&




('"

	



 





& )

 


	



 *
(


	


(





(+(
(




&









(
,


(
-



.&*
/&01	&


  	

	  	

	
 
 





   
 

 
   


!	" # 

	 

 
 $%&! 	
%

&! 
'  	
	
	
			
		 				
				
				
							   		
	!	"			#$%								
		
	&
"			' 	

 &"			
		(			)	"				*	+,-			.(/00	
	 

 		-	#$%)				-		-"	
	).
			&
		-								
	

###  	

 

 




  


 !"#$%%!"#$""&%&&'&( 

)*!%





)
 


)
)

+


)#,-#!"
,.

/ 

0

 0



)11

)234
 !"#$




)%(%
%%52%(
!"#$
56(



)
07
8 966-119
#, 966-119
#,011 966-119
#,019"8 :115119
#,%6;0



)8 -	8 966-19<966=1:5
-#

966-19<966=1:5
-#011 33 
8 966-1
:966=1=1
!"

966-1
:966=1=1
!"011 338 966-119966=
=>
,.

966-119966=
=>
,.011 33-	


)


)
)

?




@#


)
( 


  ()
>%
	

)
)

%9

###  	





	



		
	



 	




 
			 	

	
			
 	



 

 



			


 
 
   !	"  #$%&	%'$()"*%+'$()"*%'),%$,-,%'  
 %&	% 

 
.
 
 
)/*0*1+	
		
		
	
	
"++,2
			





   
		
	
2		

	
		
 3333"""44((%% !
" 
 !*12


	
 !
"# 
	


	
  
 


			

			 	

		
	 $


 
	
	

	

5		

				
			 	

		
	 $

 


  		
			




	




					

		
	 %&  
		


 	 2


	
 !'  !&'  &'!  %"%	 6


### 	

		
	



	





 	 	

 		   	!"#$"$ 		   	"%"%! 		  



 		
		
 	
& 	'#($
))*+ ',$ ++*'-...$*)+'".% /&*)++' 0"% /& 	

 12++312



 
		
 	
)& 3 +'(*)& 31 +'(* 21 +&',$4!4#.4%,.4%%%40".4"0%4(0%* 5',.* )3+ 3 12',%(!% &+*5',$(%*'0*&'"",.  ! 	



 	 "	#

$  	33 +3 #  *)+  	$ 3 6+ %		 2 "
 ! '
(+
4
&
4

 "	! $  	78+333 +3 !  * )+ 	$ 3 6+ %		 2 "
 ! '
(+
4
&
4 
 "	&#

$  	3+3 +3 &#  *)+ 	$ 3 6+ %		 2 "
 ! '
(+
4
&
4

 "	&! $  	78+33+3 +3 &!  *)+  	$ 3 6+ %		 2 "
 ! '
(+
4
&
4

  	 	783)+)*++34+34)4&)4+4+33+3&3 9999::77

 & 	 	+783)+)*++34+34)4&)4+4+33+3&3 9999::77

 #

$  	783+3)+)

###  	

 	

 		  	

		

	

		 	

 		  		  	

			   	

		
  

### 	
! 			
"#$"	  	

		 % 	   & 
 '  ()) 				
		 '				
  (*  	'	(  	"#$"	   	

		  				
		 '				
  '
	+	 !  

### 	
!			 "#$"	

 
)
,)%	-	  
)
.)%		
-	!
  
						
	!
  
					
	 "

  
	 '				
	
  
		
				
	  	

			%+		 			
  
			
		  
			

-	
	
 &	 

###   	



 	


 




	
		   	

 


   	









 
 


!"
#





	







	


	
	
	

 


	

	


 
 
 
 










	

 

  
  



  $ 	%
 #&'








	
 

 $ 	%
 #( '




	

)
 *  $ 	%
 #	)


	
 
! + 	%
 #,-+.-'/
0


1


" #$ + 	%
 #2(('





" #!$ + 	%
 #2(('





 # + 	%
 #.+(('



% 
 &
"&
" 

 &
" 
 &
" 








	



	


 










	

!"



%	
' #! $ 	%
 #
3

 &
"  ( + 	%
 #3 

	

 $( + 	%
 #
3
	

'
 ,(4  )


.5((
  #! $ 	%
 #	
	
 


  '

%

  $ 	%
 #	
	





	

 #! 

### 	

			 	


 	

			
	
   

      				
		 			!					  "#    	

				 	 		
	    $ 	

	%					

 $ 	

				
		  $ 	

					  

%			  
	
		
				
	 	  $ 	

$			
	&% $ '   "(					
    %!"# )&% 		  	
  $ %   #"! *&% 					
 %+,*
				 -		  	
 		
		  &&& .%	
	 / $ 

###  ( 

###  ( 

### /// /// 		%	
	%			 %			)( &&& 	
	///012	)(       		
	

	
  

###  	


###  	









  






	



 !"#

 $	



 !"#

	



 !"# %
 &'





	'(

	

'	

	
 &'







'
  
'

  (
(	)
(  
'

  $ *#
'	')
	'#





   $ *#

'	+
	')
	'#



	'
'


' 	'





	



	



'#''



  
# 


'#	
''





  
# (
'



+
	



'''

"," -
&./(0')1

''

	'




##"!0"2*.''


	'
#

  !"#


$% &'


 & 	
 " 

'	
		'	


)
' & #

+

#	
#



'



'
3

4
/(4

+

#



'


	#+

#
'
(

+

#


2/'

	



'

###  	
	
	
		
	

	


		


  !" # #$# %& %& %& %%' %%' %%' %%' %() %** %() +) ,& +' ,& +&) ,& +&) ,& +++ ++ +-+ ++) -.) --. -.) -.) ,' .-+ .%* .-+ .+) *-+' *-(' *-+' /
0  &/
0 	
 '/
0