netCDF Conventions for Satellite Data

This document was completed 5/11/95 by Andrew Sundelin of NOAA/FSL.

History:

At the February 1995 NUWG meeting, I presented FSL's first cut at a netCDF description of remapped and un-remapped satellite data for consideration as conventions for these data types. Discussion of remapped satellite data was tabled because it is nominally the same as gridded data. Discussion of un-remapped satellite data continued at that meeting, as well as at the March and April meetings. This is a summary of what we have concluded as of the April meeting.

This discussion should be read in conjunction with the FSL's sample CDL for un-remapped satellite data.

Questions arose concerning several different issues:

These are discussed individually and followed by a summary.

Navigation

The most obvious thing that came up concerning satellite navigation was that the commonly used techniques and libraries for navigating satellite data were generally not compatible with the GRIB parameterization of satellite data. We developed 4 conventions:

  1. Equivalent parameterizations of navigation information are equally valid in the eyes of NUWG. Users can then determine which navigation best fits their needs or their applications. 
    eg. the parameterization of GOES-8 navigation information developed
    by SOCC to describe its orbital elements is equally as valid as
    the GRIB Edition 1 specification of satellite navigation since
    they should create equivalent mappings from indicial space to
    lat-lon space.
  2. Each equivalent parameterization of navigation information should be dimensioned by a unique navigation dimension. 
    eg. GRIB parameterization variables might be dimensioned by gridnav, 
    and native satellite navigation variables might be dimensioned
    by satnav.
  3. Each equivalent parameterization should be contained in the :navigation attribute string of the variable(s) to which the navigation applies. 
    eg. image:navigation = "satnav, gridnav"
  4. A new variable should be added to all navigation psuedo-structures to identify the model/parameterization used in the particular navigation. This applies to all navigable data -- not just satellite data. A set of these may be conventionalized by NUWG in the future to unambiguously represent a given parameterization, thus simplifying automatic interpretation of navigation information. 
    eg. 	char	satnav_model(satnav, navLength);
		satnav_model:long_name = "Satellite Navigation Model";
	data:
		satnav_model = "GOES-8 Kamel";

We did not attempt to explicitly solve the problem of polar orbiter data, where the navigation varies on a line-by-line basis. However, we believe that such a navigation scheme can be extrapolated from what we have outlined here.

Time

Temporal discontinuities may become common in satellite images in the future, especially in the GOES series. This is because the GOES series now can interrupt the scanning of standard frames with the scanning of so-called priority frames. Our discussions of this revealed that when dealing with meteorological data temporal aliasing can cause significant problems, including anything from apparent enlargement of existing storm systems to entirely missing actual storm systems, depending on the conditions.

Thus, the NUWG strongly recommends that satellite data from GOES satellites (and other satellites that have interruptable images) contain time values on a line-by-line basis.

Calibration

On the GOES series of satellites, several different detectors acquire data at the same wavelength simultaneously as the scan mirror tracks across the face of the planet. Each of these detectors has its own calibration characteristics. While at full satellite resolution (or a multiple of it) short cuts can be taken to simplify the unambiguous representation of calibration information, at other resolutions this can quickly become difficult.

For example, on GOES-8 there are two separate detectors for 11u data. These separate detectors provide nominally 4km data. At full satellite resolution it is tempting to just identify the calibration parameter for the even lines and the calibration parameter for the odd lines. However, if we wanted 1/5 resolution data (nominally 20km data) then this odd-even scheme would break down and not allow users to accurately calibrate their images.

Thus, the NUWG strongly recommends that satellite data acquired from multiple independently-calibrated detectors (such as on the GOES series) contain calibration information on a line-by-line basis.

X & Y Dimensions

With gridded data, the NUWG conventionalized the use of the variables x_dim and y_dim which would be dimensioned by a navigation dimension so as to be included in the navigation psuedo-structure. In this manner, the horizontal and vertical coordinates of the mapped data could be explicitly determined programmatically. However, this doesn't generalize to multiple, equivalent navigations of the same data all that elegantly because the horizontal and vertical coordinates of the mapped data are independent of the navigation.

I believe that we decided that x_dim and y_dim would only be included for navigation situations where they are explicitly required. For example, a GRIB parameterization may require these dimensions to be named, but the SOCC Kamel parameterization may not.

Summary:

  1. Equivalent navigation parameterizations are equally valid.
  2. Each equivalent parameterization of navigation information should be dimensioned by a unique navigation dimension.
  3. Each equivalent parameterization should be contained in the :navigation attribute string of the variable(s) to which the navigation applies.
  4. A new variable should be added to all navigation psuedo-structures that identifies the model/parameterization used in the particular navigation. A set of these names may be identified by NUWG at a later date.
  5. Time should be represented on a line-by-line basis if the possibility of temporal aliasing exists.
  6. Calibration information should be represented on a line-by-line basis if the possibility of calibration ambiguity exists at any resolution.
  7. x_dim and y_dim-style variables should exist for navigation parameterizations that are ambiguous in their absense. However, they are not required for all navigation models.