Technical Support Document for U.S. EPA’s Proposed Rule for Numeric Nutrient Criteria,

Volume 2 Coastal Waters

Appendix A.

Appendix B: Supporting Documentation 

for Remote Sensing Methods

November 30, 2012
Technical 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, 2007
2
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

3
4 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 Web
1.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, Ca

– Diffuse attenuation, Kd(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 Ca and Kd 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 (Zeu, Zsd)

– Subsurface PAR at 1st optical depth, Kd(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 Page
1.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), where

announcements 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.

9
10 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 contains

all 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 sensor

counts 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 process
12 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 standard

suite of products including water-leaving radiances, chlorophyll a concentration, the diffuse attenuation coefficient at

490nm, and a few other products. In addition, thirty-two

flags 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 oceanic

optical 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 Daily
2.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 automatically
14 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).

17
18 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 Browser
3.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 Results
20 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 the
3.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 Form
3.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

25
26 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.

29
30 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 the

viewable 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 Window

Alternatively, 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 portion
5.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 28 = 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

33
34 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 245

colors, 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 control
6.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.

39
40 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 then

temporarily 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 graphic

that 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 states

can 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 Product
7.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) Function
44 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 + v2). 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 and

arrows, 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 be

recognized 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” to
7.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

49
50 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

51
52 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

53
54 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:

•

55
56 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

57
58 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

59
60 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:

61
62 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 Window
14.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 situ

data 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 parameters

for 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 Window
68 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

69
70 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

71
72 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 image

depicting 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 performs
16.5. PROCESSING USING THE SEADAS COMMAND-LINE 73

atmospheric corrections to derive a Level-2 file of normalized water leaving radiances (Lnw), chlorophyll

concentration, 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.dat
74 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

77
78 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.

79
80 CHAPTER 18. CREATING TRUE COLOR IMAGES

18.1.1 Rayleigh correction

Figure 18.1: Generating an RGB Image

As the photons of light pass through the atmosphere, they interact with molecules in the atmosphere. This interaction produces

what 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 not

corrected, 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 most

people are familiar with. The curvature of the Earth, the inclination of the satellite orbit and the way the satellite sensor scans, all

combine 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 another

method 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 Widgets
18.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/doc
82 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 input

L1[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 modifications

c. 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

83
84 CHAPTER 19. ADVANCED TOPICS
Chapter 20

msl12 —In Depth

Goal

The following exersize explores the multi—sensor level-1 to level-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.

85
86 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:

•

87
88 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

89
90 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 NASA/GSFC 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; concatenated
digits 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 discrete
telemetry"; 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 Tilt
The 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) degrees
24 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 Spares
Table 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 Spares
Table 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 spares
Table 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 

short 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 the 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). 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 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 

geophysical 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 SeaWiFS 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 the UTC year, day of the year, hours, minutes, and 

seconds of the first scan line, rrr is the resolution, and ppp is the product identifier (OC for ocean 

color or SST for sea surface temperature. 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 merged 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 section 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 Data”.

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; concatenated 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 delimiters. 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 ancillary (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 (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.
3.1.2 SeaWiFS-Specific Attributes

Data Center (character): "NASA/GSFC SeaWiFS Data Processing Center".

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 

digits 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 fraction 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 milliseconds-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 

scene.

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.

Number 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 separated 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 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) (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 inverse 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 nth values of all data objects in these four groups would need to be read.

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. 

year (4-byte integer, array size Number of Scan Lines): long_name = "Scan year"; 

valid_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, 

milliseconds 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 real, 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 = "degrees".

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 products 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 intercept 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 integers, 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

Kd_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 none 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

Photosynthetically 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) 520 (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) Used 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 for 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 

l2_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 epsilon 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 surface 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 SPARE

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 Surface 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 Navigation

4.3.1 Navigation Control Points and Tilt

The following data objects are SDSs 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 Control 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 points";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 SDSs belonging to the Vgroup "Navigation" in 

SeaWiFS data products. 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.

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 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.4 Sensor Tilt (SeaWiFS only)

The following data objects are SDSs 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 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.

4.5 Sensor Band Parameters

The following data objects are SDSs belonging to the Vgroup "Sensor Band Parameters". 

Attributes 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 size 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 sr^-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

33

8 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+312',%(!%&+*5',$(%*'0*

&'"",.

 !	



 	

"	#$ 	33 +3#*)+

	$
36+%		2"
 !'
(+
4
&
4



"	!$ 	78+333 +3!*

)+	$
36+%		2"
 !'
(+
4
&
4





"	&#$ 	3+3 +3&#*)+

	$
36+%		2"
 !'
(+
4
&
4



"	&!$ 	78+33+3 +3&!*)+

	$
36+%		2"
 !'
(+
4
&
4



 		783)+)*++34+3

4)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