Sorry, you need to enable JavaScript to visit this website.

Data Overview

CAR data is widely distributed through NASA Goddard Earth Science Data Information and Services Center (GES DISC).

In support of CAR related research, a CAR data processing system was designed and implemented by the CAR project team at NASA Goddard Space Flight Center. The purpose of the processing system is to ingest CAR raw digital counts and engineering data, and produce calibrated radiances in NetCDF (network Common Data Form). The end product is a self-contained, self-describing, and information-rich data set.

By clicking on one of the field experiments to the left, one may obtain detailed information on each of the CAR missions for that experiment, including:

• CAR quicklook images
• Flight track map,
• Flight log
• Coincident satellite images
• netCDF data distribution information

Note that CAR is a fourteen spectral bands radiometer between 0.30 and 2.30 µm, located in the atmospheric window regions of the UV, visible, and near-infrared.  One of the strengths of this instrument is its unique ability to measure, almost simultaneously, both downwelling and upwelling radiance at 14 narrow spectral bands (see Table 1).

As the CAR scan mirror rotates 360° in a plane perpendicular to the direction of flight, data (60 MB/hr) are collected through a 190° aperture that allows observations of the earth-atmosphere scene around the starboard horizon from local zenith to nadir. This unique viewing geometry, makes it most suitable for measuring surface bidirectional reflectance-distribution function (BRDF) even under low sun conditions with a better accuracy than any other known airborne sensor.  Data are acquired at a high angular (1°) and spatial (better than 10 m at nadir, assuming 600 m altitude) resolution, coupled with a high signal-to-noise ratio. In addition to the starboard viewing mode, the CAR instrument can be rotated in-flight into any viewing positions, e.g., downward-looking imaging mode, where the CAR views 190° of the Earth scene from horizon to horizon and upward-looking imaging mode, where the CAR views 190° of the sky above the aircraft from horizon to horizon.

During operations, CAR is stabilized by an independent system (CAR Autonomous Navigation System, CANS) that corrects the sensor with respect to aircraft roll in real time based upon inputs from a precision navigation sensor. This stabilization ensures that the resulting data and imagery are clear and require little to no post-processing for correction due to aircraft motion. Radiometric calibration of the CAR is performed at GSFC.

TABLE 1: CAR BAND CONFIGURATIONS/30-YEAR PERIOD

1994-1998

 Band Index Central Wavelength[bandpass] nm 1984-1993 1999-2011 2014 1 502 [16] 472 [21] 472 [21] 480 [21] 2 673 [20] 675 [20] 682 [22] 687 [26] 3 754 [19] 300 [??] 340 [9] 340 [9] 381 [6] 381 [6] 4 866 [20] 868 [20] 870 [20] 870 [10] 5 1031 [20] 1038 [20] 1036 [22] 1028 [4] 6 1220 [22] 1219 [21] 1219 [22] 609 [9] 7 1270 [21] 1271 [22] 1273 [23] 1275 [24] 8 1547 [30] 1552 [30] 1556 [32] 1554 [33] 9 1640 [41] 1643 [41] 1656 [45] 1644 [46] 10 1722 [38] 1725 [38] 1737 [40] 1713 [46] 11 2100 [39] 2100 [39] 2103 [44] 2116 [43] 12 2200 [40] 2207 [40] 2205 [42] 2203 [43] 13 2289 [23] 2302 [23] 2302 [43] 2324 [48]

DATA:

Since the CAR data are stored and distributed as NetCDF-4, we use the framework (and naming conventions) developed for the NASA Earth Observing System Data and Information System (EOSDIS).

The advantage of using netCDF allows sharing of self-describing files across different platforms (portable) such that a DEC ALPHA machine can read an netCDF file generated on a Silicon Graphics machine — where ordinarily the byte ordering of binary files would need to be considered.  The netCDF library functions take care of such details. It also implies that a data set, such as a multi-dimensional array of numbers, can have additional metadata logically associated with it that describe things such as the rank of the array, number of elements in each dimension, etc.

netCDF is based on the principles of object-oriented programming, where multidimensional arrays, tables and images can be stored in the same file and viewed as discrete objects, rather than a continuous stream of bits.  Users interact with these objects only through calls to an netCDF library and therefore knowledge of object-oriented programming and of the physical layout of the files is unnecessary. What’s most important is for the user to understand the content of the file being accessed in terms of the various netCDF data object types.

We adopted the EOSDIS data processing levels, but modified them to suit the CAR data needs (http://science.nasa.gov/earth-science/earth-science-data/data-processing-levels-for-eosdis-data-products/)

 Data level Description Level-0 Refers to instrument and aircraft data at full resolution combined into one file and stored as digital numbers from 1-65,536. The level-0 also contains communication headers and any communication artifacts. Level-1A In level-1A processing, the Level-0 data are separated out into four data types: header data (include aircraft navigation data such as roll, pitch, heading, altitude, latitude, and longitude), science data (10 channels; the 10th channel is reserved for future use), dark current, and engineering (e.g. instrument status info, temp data for detectors and optics, etc). Data is at full resolution, time-referenced, and information on radiometric calibration coefficients appended but not applied. Quicklook RGB images (at single wavelength or using three different wavelengths) are generated to help with the review of data qualitatively. Level-1B In level-1B processing, final radiometric calibration coefficients are applied to Level 1A data for conversion to sensor radiance units by the user. Data for each scan line is also georeferenced using parameters such as aircraft pitch, roll, and heading. Each scan line contains 382 pixels (representing a 190° field of regard). Level-1C In Level-1C processing, georeferencing parameters are applied to Level 1B data for each scan line. Each scan line contains 361 pixels (representing a 180° field of regard). CAR data is expanded into 14 two- dimensional arrays and engineering data is excluded. Global attributes are kept to a minimum. Level-1D In Level-1D processing, we extract the data collected during the CAR circular flight tracks during the BRDF measurements for each circle. This is the data that we typically refer to as BRDF measurements. Level-2 Derived geophysical variables at the same resolution and location as Level 1 source data. Level-3 Variables mapped on uniform space-time grid scales, usually with some completeness and consistency. Level-4 Model output or results from analyses of lower-level data (e.g., variables derived from multiple measurements).

Next section describes CAR data object types for CAR Level-1 products. Note that higher data levels are not currently available.

SCIENTIFIC DATA SETS (SDSS)

The CAR netCDF Data Objects used in Level 1 files uses data objects that are supported by netCDF to store science, calibration data and associated metadata, which describe the scope and quality of science data.

These objects contain multidimensional arrays, used to store scientific data.  For example, Level 1C employs SDSs to store calibrated science data and any information on the quality assurance data.  The SDSs are made self-describing through a set of attributes — data that may be considered "attached" to the SDS.  Table 1 below shows various components of an SDS Array. The required components are shown on the second column, and the optional components are shown on the third column.

Table 1:  SDS Arrays contains both “Required Attributes” and “Optional Attributes”

 Required Attributes Optional Attributes SDS Array Name Predefined attributes, e.g. label, fill values, etc. Data type (in16, float32, etc.) User defined attributes Dimension Dimension, scale

So the Required Attributes needed to provide the minimum information to allow an HDF library to identify the SDS, and organize the data into an array having the correct dimensions and data type are:

• Name: A string that defines the name of the SDS and uniquely identifies it.
• Data Type: Type of data (e.g., float 32, int 16, etc.) that defines how the data in the array are stored.
• Dimensions: The number of dimensions, or rank, of the array.

All other attributes are optional attributes.  For example,

• Predefined attributes, can include:
• Labels for all dimensions and for the data
• Units for all dimensions and for the data
• range specifying maximum and minimum values for the data set.
• fill value for representing missing data in a data set.
• coordinate system to use when interpreting or displaying the data
• User defined attributes:       can use this feature to define dedicated calibration scale and offset parameters for the calibrated products.
• Dimension scales:    Scales to be used along the different dimensions when interpreting and displaying the data

Data collected during any field campaign mission is arranged by flight, where each flight is defined by: aircraft takeoff to aircraft landing.  Data collected during each flight has a name in the form:

dataID_platform_measDate_revision_comments.extension

For example, for the DISCOVER-AQ mission, the dataID is “discoveraq-CAR”, platform is “p3b”, and extension is “hdf”. Comments would be the place for additional information about the file, such as product level, processing date, and unique identifier.  The revision should be “R#”, where # corresponds to the number of times data has been revised for the particular file or data product.  So all CAR Level-1C data files names for the DISCOVER-AQ/Colorado mission looks like this:

discoveraq-car_p3b_20140708_R0_2037-Level1C-20150613.hdf

Where “2037” is a 4-digit number (based on historical CAR data records) and is unique to each flight. The first calendar date (yyyymmdd: year, month and day) is when the data was acquired and the second calendar date is when data was processed or last updated (yyymmdd).

Likewise, all CAR Level-1D data files names for the DISCOVER-AQ/Colorado mission looks like this:

discoveraq-car_p3b_201407221451_R0_CAR2042-Level1D-20150815.hdf

Where “2042” is a 4-digit number (based on historical CAR data records) and is unique to each flight. The first calendar date (yyyymmddhhmm: year, month, day, hour and minutes) is when the data was acquired including the start time of BRDF measurements, and the second calendar date is when data was processed or last updated (yyymmdd).

CAR quicklook images for each mission, e.g.  DISCOVER-AQ/Colorado mission can be found at: https://car.gsfc.nasa.gov/missions/discover-aq

Each HDF data file contains calibrated Earth and/or sky view observations for CAR bands 1-9, where the 9th band is selected among the filter wheel (see Table 1, bands 9-14). Data contains:

• Global Attributes: General information about the flight and the data set
• Dimensions: Denote the size of the arrays, and
• Arrays and their Attributes: Physical data parameters as a function of time. Attributes describe each array.

DATA CONVERSION (FROM RADIANCE TO REFLECTANCE)

The radiance data can be converted to reflectance following van de Hulst [H. C. van de Hulst, Multiple Light Scattering, Tables, Formulas, and Applications, vol. 1., San Diego, CA: Academic, 1980] formulation:

Rλ(θ, θ0, Φ) = πIλ (θ, θ0, Φ)/ μ0 Fλ

where Iλ is the measured reflected or scattered intensity (radiance), Fλ is the solar flux density (irradiance) incident on the top of the atmosphere, assuming mean-earth distance, θ and θ0 are the viewing and incident zenith angles, respectively, Φ is the azimuthal angle between the viewing and incident light directions, and μ0 = cos θ0. The viewing directions range from 0 –180°. The relative azimuth angles range from 0 to 360°, where degrees coincide with the solar principal plane.

Level-1C and Level-1D contain SDSs for each of the variables defined above. Also, Level-1D is converted into reflectance units.

Note: All bands saturate when looking at the solar disk. We have not yet developed a good way to identify and flag the saturated pixels; we hope to do so in future. For now, measurements close to the sun should be assumed to be saturated in all bands. For similar reasons, measurements over very bright clouds or sunglint saturate several bands in the visible (472 nm, 682 nm) and NIR (872 nm).