**Content Standard for Remote Sensing Swath Data**

Standards Working Group

Federal Geographic Data Committee

August 1999

Federal Geographic Data Committee

Established by Office of Management and Budget Circular A‑16, the
Federal Geographic Data Committee (FGDC) promotes the coordinated
development, use, sharing, and dissemination of geographic data.

The FGDC is composed of representatives from the Departments of
Agriculture, Commerce, Defense, Energy, Housing and Urban Development,
the Interior, State, and Transportation; the Environmental Protection
Agency; the Federal Emergency Management Agency; the Library of
Congress; the National Aeronautics and Space Administration; the
National Archives and Records Administration; and the Tennessee Valley
Authority. Additional Federal agencies participate on FGDC subcommittees
and working groups. The Department of the Interior chairs the committee.

FGDC subcommittees work on issues related to data categories coordinated
under the circular. Subcommittees establish and implement standards for
data content, quality, and transfer; encourage the exchange of
information and the transfer of data; and organize the collection of
geographic data to reduce duplication of effort. Working groups are
established for issues that transcend data categories.

For more information about the committee, or to be added to the
committee\'s newsletter mailing list, please contact:

Federal Geographic Data Committee Secretariat

c/o U.S. Geological Survey

590 National Center

Reston, Virginia 22092

Telephone: (703) 648-5514

Facsimile: (703) 648-5755

Internet (electronic mail): gdc@usgs.gov

Anonymous FTP: ftp://fgdc.er.usgs.gov/pub/gdc/

World Wide Web: http://fgdc.er.usgs.gov/fgdc.html

CONTENTS

Page

1 Introduction [1](#introduction)

1.1 Objective [1](#objective)

1.2 Scope [1](#scope)

1.3 Applicability [1](#applicability)

1.4 Related Standards [1](#related-standards)

1.5 Standards Development Procedures
[2](#standards-development-procedures)

1.6 Maintenance Authority [3](#maintenance-authority)

2 The Swath Concept [4](#the-swath-concept)

2.1 What Is a Swath [4](#what-is-a-swath)

2.2 The Components of a Swath [8](#the-components-of-a-swath)

2.3 Defining a Swath [9](#defining-a-swath)

2.3.1 Sensor Data [9](#sensor-data)

2.3.2 Defining Geolocation [10](#defining-geolocation)

2.3.3 The Relationship between Geolocation and Sensor Data
[13](#the-relationship-between-geolocation-and-sensor-data)

3 References [15](#references)

Appendix A (Normative) - Glossary OF TERMS AND ACRONYMS
[16](#appendix-a-normative---glossary-of-terms-and-acronyms)

Appendix B (Informative) - Examples of Dimension Mappings Encoded with
ODL
[17](#appendix-b-informative---examples-of-dimension-mappings-encoded-with-odl)

Appendix C (INFORMATIVE) - An Example Swath
[20](#appendix-c-informative---an-example-swath)

FIGURES

Page

Figure 2‑1 Physical View of a Simple Swath: a Time-ordered Series of
Scan Lines [4](#__RefHeading___Toc455899750)

Figure 2‑2 Physical view of a swath derived from ground-based radar: a
time-ordered series of sweeps [5](#__RefHeading___Toc455899751)

Figure 2-3 Data view of a sample swath: a time-ordered series of scalars
and arrays [6](#__RefHeading___Toc455899752)

Figure 2-4 Data view of a sample swath: Attitude/ephemeris used for
geolocation [6](#__RefHeading___Toc455899753)

Figure 2-5. Geolocation Table with 1D Geolocation Information Included
[11](#__RefHeading___Toc455899754)

Figure 2-6. Geolocation Array containing Latitude and Longitude planes
[11](#__RefHeading___Toc455899755)

Figure 2-7. One-dimensional Attitude/Position Geolocation Table
[12](#__RefHeading___Toc455899756)

Figure 2-8. Geolocation Array containing Attitude and Position planes
[13](#__RefHeading___Toc455899757)

Figure C-1. Conceptual View of Example Swath, with 3D Array,
Time/Geolocation Array, and Geolocation Table.
[20](#__RefHeading___Toc455899758)

TABLES

Page

Table 2-1. Dimension definitions for a generic scanning instrument
[7](#__RefHeading___Toc455896289)

Table 2-2. Dimension definitions for a generic profiling instrument
[7](#__RefHeading___Toc455896290)

Table 2-3. Dimension definitions for a generic scanning-profiling
instrument [8](#__RefHeading___Toc455896291)

Table 2-4. Possible Components of a Swath Structure
[9](#__RefHeading___Toc455896292)

Table C-1. Components of Example Swath.
[21](#__RefHeading___Toc455896293)

#  Introduction

##  {#section .unnumbered}

##  Objective

> The primary objective of this standard is to define the minimum
> content for remote sensing swath data (hereinafter called the swath
> data model). This content standard will provide a solid basis for
> developing interoperable data formats for remote sensing swath data.
>
> The standard has the following goals:
>
> 1\. To provide a common conceptual framework for encoding swath and
> swath-like data,
>
> 2\. To encourage interuse of swath and swath-like data through
> implementation of transfer standards within the conceptual framework,
>
> 3\. To involve non-federal organizations in the development of this
> standard, thereby encouraging broad applications.

##  Scope

> The standard defines the minimal content requirements for a remote
> sensing swath and the relationships among its individual components.
> It also discusses the treatment of optional supporting information
> within the swath model. In the classification system of the Federal
> Geographic Data Committee Standards Reference Model (FGDC 1997), this
> standard is a **Data Content Standard**. Data content standards
> provide semantic definitions of a set of objects and of the
> relationships among them. This standard defines a concept called a
> *swath* that provides a means for associating certain kinds of remote
> sensing data with their geolocation. To that end, it defines those
> items of information content that are necessary for the realization of
> the swath concept. As a content standard, the Content Standard for
> Remote Sensing Swath Data does not specify encoding. Encoding may be
> specified at some future time by a separate standard or standards.
>
> The standard specifies only the information that varies with time or
> from pixel to pixel. Information that is constant for all data points,
> such as the axes about which platform roll, pitch, and yaw are
> measured or the orientation of individual instruments relative to the
> platform, would be specified elsewhere, for example, in a content
> standard for remote sensing metadata.

##  Applicability

> The swath data standard for remote sensing supports the development of
> the National Spatial Data Infrastructure (NSDI) by providing a common
> framework for the organization of a wide range of remotely sensed
> data. The standard will be particularly useful for data from scanning,
> profiling, staring, or push-broom type remote sensing instruments,
> whether they be ground based, shipboard, airborne, or spaceborne. It
> is intended for use by organizations that produce remote sensing data.
> The standard addresses the content of the data that are produced by
> such an organization, as when populating an archive, not the
> requirements on data to fulfill particular user needs.

##  Related Standards

> The Content Standard for Remote Sensing Swath Data is an outgrowth of
> standards work done for the Earth Observing System Data and
> Information System (EOSDIS), part of the Earth Observing System (EOS),
> under the National Aeronautics and Space Administration (NASA) Mission
> to Planet Earth. As such, it draws heavily on the NASA EOSDIS concepts
> and data model for remote sensing swath data, described in a Hughes
> Applied Information Systems (HAIS) White Paper (HAIS 1995), which, in
> turn, had been developed from existing standards. The NASA model
> specifies the minimal content requirements for a swath and the
> relationships among its individual components. The EOSDIS project has
> developed an encoding mechanism and a set of software tools, described
> in Raytheon Systems Corporation (RSC) papers (RSC 1999a, 1999b) based
> on that model. Although those tools are related to this content
> standard, the standard does not depend upon them. In fact, the tools
> rely on the existing EOSDIS data model.
>
> The ISO TC211 Imagery and Gridded Data Project is investigating how
> imagery and gridded data need to be supported within the ISO 15046
> suite of standards. A report preliminary to that activity identifies
> support for the EOSDIS data models as essential and cites the swath
> model as presented in a draft of this standard.
>
> The Committee on Earth Observation Satellites (CEOS), an international
> information exchange body, has endorsed the development of data models
> for remotely sensed swath data, specifically including the one
> described in this standard, through the Data Subgroup of its Working
> Group on Information Systems and Services (WGISS).
>
> The Spatial Data Transfer Standard (SDTS), originally published as a
> Federal Information Processing Standards (FIPS) publication (FIPS
> 1994) addresses the transfer of geospatial data among computer
> systems. The SDTS Raster Profile (FGDC 1999), because it can be used
> to transfer remote sensing data, is remotely related to the proposed
> swath standard. However, the SDTS Raster Profile is a transfer
> standard, while the proposed swath standard is a content standard.
> While the SDTS Raster Profile probably could be adapted to transfer
> remote sensing swath data, there is no overlap between the standards,
> because they deal with different data standards described by the FGDC
> Standards Reference Model.
>
> No other current FGDC, national, or international standard addresses
> this facet of sharing remote sensing swath data.

##  Standards Development Procedures

> This standard has been developed by the Imagery Subgroup of the FGDC
> Standards Working Group (SWG). This group consists of members from
> NASA, the National Oceanic and Atmospheric Administration, the U. S.
> Geological Survey, the University of Illinois, the University of
> Wisconsin, and the OpenGIS Consortium. An initial working draft,
> discussed by Di and Carlisle (1998) at a meeting of the annual meeting
> of the American Society for Photogrammetry and Remote Sensing (ASPRS),
> was reviewed by the SWG Imagery Subgroup. The draft was then revised
> in accordance with these comments, where appropriate, and the author
> of the comments was notified that the comments had been incorporated
> or provided an explanation of why comments were not incorporated. The
> revised draft was then submitted to the Imagery Subgroup, and, as
> there were no further changes recommended, to the SWG.
>
> The development of this standard is guided by the FGDC Standards
> Reference Model (FGDC 1997). The Standards Reference Model, developed
> by the SWG of the FGDC, provides guidance to FGDC subcommittees and
> working groups for the standards development process. It defines the
> expectations for FGDC standards, describes different types of
> geospatial standards, and documents the FGDC standards process.

##  Maintenance Authority

> The NASA Earth Science Data and Information System (ESDIS) Program
> maintains this standard for the Federal Geographic Data Committee.
> Address questions concerning this standard to
>
> NASA Goddard Space Flight Center
>
> Code 505
>
> Greenbelt, MD 20771.

#  The Swath Concept

##  {#section-1 .unnumbered}

##  What Is a Swath

> A *swath* is produced when an instrument scans perpendicular to a
> moving point. Perpendicular, in this context, means close to, but not
> necessarily precisely at, a 90° angle. The path of this point, along
> which time or a time-like variable increases or decrease
> monotonically, is defined as the *'Track'* dimension (sometimes
> referred to as 'along track'). The direction of the scan, which is
> perpendicular to the 'Track' dimension, is called the *'Cross-Track'*
> dimension. Determining geolocation depends on knowing which array
> dimensions correspond to the 'Track' and 'Cross-Track' conceptual
> dimensions. Other conceptual dimensions, such as 'Detector', 'Band',
> 'Channel', and 'Parameter', also can be defined. However, since these
> dimensions are not used for geolocation, this standard does not
> prescribe their usage. The swath concept can be applied to
> measurements from a variety of platforms, including satellite,
> aircraft, and surface.
>
> A typical satellite swath consists of a series of instrument scans
> perpendicular to the ground track over which the satellite moves.
> Figure 2-1 shows this traditional *physical* view. The term *swath* is
> sometimes used to refer to a single scan of the instrument\'s various
> detectors. For the purposes of this standard, however, a series of one
> or more scans is considered to form a swath. For this example, the
> 'Track' dimension, the moving point, corresponds to the ground track
> and the 'Cross-Track' dimension to the direction of the scans
> perpendicular to it. The instrument records its measurements at
> discrete points along the track. The same concepts are also applicable
> to airborne platforms.

![](media/image3.wmf){width="4.375in" height="3.025in"}

[]{#__RefHeading___Toc455899750 .anchor}Figure 2‑1 Physical View of a
Simple Swath: a Time-ordered Series of Scan Lines

> An example of the application of the swath concept to ground-based
> data is a radar map. Figure 2-2 provides an illustration. The
> instrument sweeps in an azimuthal direction, with each sweep beginning
> and ending along a particular radial path. In this case, the 'Track'
> dimension corresponds to the radial path corresponding to the
> beginning and end of a sweep (labeled T in the figure), while the
> 'Cross-Track' dimension corresponds to the direction of the sweeps
> (labeled CT in the figure). Note that in this case, the two orthogonal
> dimensions are those of a polar coordinate system, while in the case
> of airborne and spaceborne measurements, the two dimensions were those
> of a rectangular coordinate system.

![](media/image4.wmf)

[]{#__RefHeading___Toc455899751 .anchor}Figure 2‑2 Physical view of a
swath derived from ground-based radar: a time-ordered series of sweeps

> In the *data* view of a swath, the data are ordered by *time* or a
> *time-like variable* (e.g., scan line counter). Every scan consists of
> one or more sets of date/time and/or geolocation information (e.g.,
> latitude, longitude), and data. Each time entry records the time when
> one particular measurement was made. Each geolocation set corresponds
> to an individual sensor measurement (e.g., a pixel) within the scan,
> and provides a means of associating the data with the latitude and
> longitude of the point on the Earth where it was taken. The data can
> be in the form of scalar values, 1D arrays of values (e.g., scan lines
> or profiles), or nD arrays of values (e.g., scan lines observed in
> multiple channels or profiles).
>
> The following examples show how the swath concept would apply in
> specific cases; they are not a complete description of swath content.
> The precise definition is provided in Section 2.3. Figure 2-3 shows an
> example of a data view of a swath.

![](media/image5.wmf)

[]{#__RefHeading___Toc455899752 .anchor}Figure 2-3 Data view of a sample
swath:\
a time-ordered series of scalars and arrays

> In this example, the information for each scan consists of a Date/Time
> value, one geolocation set (Lat/Long), two single-valued parameters
> (Param1, Param2) containing information related to the scan, and a 1D
> array of values for Scan Line Data (the sensor measurements). Thus, in
> this case, only one pixel in the entire scan has a time tag and one
> pixel, not necessarily the same one, has the geolocation tag.
> Conceptually, each named item can be considered as a separate array.
> For example, in the figure above, Date/Time would be a 1D array, as
> would Lat, Long, Param1, and Param2. The Scan Line Data would be a 2D
> array.
>
> Another way to supply geolocation information is in the form of
> attitude and ephemeris data for the observing platform. In this case,
> the geolocation data consist of date/time, the three components of the
> attitude vector  ξ~r~ (roll), ξ~p~ (pitch), and ξ~y~ (yaw)  for the
> platform and the three components of the position vector in geocentric
> coordinates (*x*, *y*, *z*) for the platform. Section 2.3.2.3 provides
> detailed information about how to define this type of geolocation. The
> data stored for a scan can consist of the sensor measurements as well
> as multiple sets of date/time and geolocation information for that
> time. Each set of date/time and geolocation are attached to an
> individual measurement (e.g., pixel) in the scan. The ways to attach
> the geolocation to individual measurements are defined in Section
> 2.3.3 Figure 2-4 shows an example of such a swath scheme.

![](media/image6.wmf)

[]{#__RefHeading___Toc455899753 .anchor}Figure 2-4 Data view of a sample
swath:\
Attitude/ephemeris used for geolocation

> In this example, the value for Date/Time has associated with it values
> for the components of the attitude vector (ξ~r~, ξ~p~,ξ~y~) and the
> position vector (*x*, *y*, *z*), scalar values (Param1, Param2), and a
> 1D array containing values for Scan Line Data. Date and Time would be
> 1D arrays, as would each of ξ~r~, ξ~p~ , ξ~y~ *x*, *y*, *z*, Param1,
> and Param2, while the Scan Line Data would be a 2D array. The platform
> attitude and position data, along with the relationship between
> geolocation and sensor data defined in Section 2.3.3, can be used with
> metadata on platform axes and/or instrument orientation relative to
> the platform to derive latitude and longitude of the measurement. In
> this example, only one set of Date/Time, attitude vector, and position
> vector is given for each scan, but more are possible.
>
> A third way to supply geolocation information, as an analytic function
> of grid position, is not illustrated here but is described in Section
> 2.3.2.2.
>
> Table 2-1 shows mandatory and optional conceptual dimensions for
> *scanning* instruments. Table 2-2 shows the same information for
> *profiling* instruments, and Table 2-3 shows the same information for
> a *combination scanning-profiling* instrument, such as the Tropical
> Rainfall Measuring Mission (TRMM) precipitation radar.

[]{#__RefHeading___Toc455896289 .anchor}Table 2-1. Dimension definitions
for a generic scanning instrument

  ------------- -------------------------------------- ---------------------
  Dimension     Description                            Comments

  Track         Path of moving point perpendicular to  Mandatory
                which instrument scans                 

  Cross-Track   Perpendicular to the track and         Mandatory
                parallel to the surface of the Earth   

  Detector      Number of footprints per dwell         Optional

  Band or       Generally used for lower level data    Optional; Band and
  Channel       that have not been processed into      Parameter are
                science parameters                     mutually exclusive

  Parameter     No physical mapping; generally used    Optional; Band and
                for higher level data that have been   Parameter are
                processed into science parameters      mutually exclusive
  ------------- -------------------------------------- ---------------------

[]{#__RefHeading___Toc455896290 .anchor}Table 2-2. Dimension definitions
for a generic profiling instrument

  ----------- --------------------------------- ---------------------------
  Dimension   Description                       Comments

  Track       Path of moving point              Mandatory; must be the
              perpendicular to which instrument first declared dimension
              scans                             

  Profile     Perpendicular to the track and in Mandatory; ordering among
              the line of sight to the Earth    dimensions other than Track
                                                is unimportant; equivalent
                                                to atmospheric level

  Detector    Number of foot prints per dwell   Optional; ordering among
                                                dimensions other than Track
                                                is unimportant

  Band or     Generally used for lower level    Optional; ordering among
  Channel     data that have not been processed dimensions other than Track
              into science parameters           is unimportant; Band and
                                                Parameter are mutually
                                                exclusive

  Parameter   No physical mapping; generally    Optional; ordering among
              used for higher level data that   dimensions other than Track
              have been processed into science  is unimportant; Band and
              parameters                        Parameter are mutually
                                                exclusive
  ----------- --------------------------------- ---------------------------

[]{#__RefHeading___Toc455896291 .anchor}Table 2-3. Dimension definitions
for a generic scanning-profiling instrument

  ------------ ---------------------------------------- --------------------
  Dimension    Description                              Comments

  Track        Path of moving point perpendicular to    Mandatory
               which instrument scans.                  

  CrossTrack   Perpendicular to the track and parallel  Mandatory
               to the surface of the Earth              

  Profile      Perpendicular to the track and in the    Mandatory;
               line of sight to the Earth               equivalent to
                                                        atmospheric level

  Detector     Number of foot prints per dwell          Optional

  Band or      Generally used for lower level data that Optional; Band and
  Channel      have not been processed into science     Parameter are
               parameters                               mutually exclusive

  Parameter    No physical mapping; generally used for  Optional; Band and
               higher level data that have been         Parameter are
               processed into science parameters        mutually exclusive
  ------------ ---------------------------------------- --------------------

> Note that the Parameter dimension in Tables 2-1 to 2-3 is not the same
> as the Param1 and Param2 columns in Figure 2-3. The contents of Param1
> and Param2 are scalar *values,* such as values of the calibration
> coefficients needed to convert count numbers to radiances. The
> elements of the Parameter dimension in the tables identify *axes* of
> the data array, such as different physical quantities measured at each
> point. Each point in the data array would correspond to a given
> (Track, Cross-Track, Parameter)
>
> To apply these concepts to a particular instrument, the producer must
> determine the appropriate dimensions to use and arrange them in an
> acceptable order (see comments in Tables 2-1, 2-2 and 2-3). The names
> given in the tables for the dimensions are meant only as points of
> reference. The data producer assigns the actual names of the
> dimensions within a swath structure.

##  The Components of a Swath

> A swath structure consists of three components:

1.  the sensor data,

2.  the geolocation information, and

3.  the relationships between data and geolocation.

> The elementary data structures for storing both the sensor data and
> the geolocation information are tables, arrays, or combinations of
> tables and arrays. A single swath structure can contain any number of
> *tables* and *multidimensional arrays*.
>
> The *geolocation information* has a special role. It allows
> identification of the geographical location on the Earth surface
> corresponding to the data measurements for an individual pixel. Every
> swath is required to contain some geolocation component. Geolocation
> information can be stored as a table, as a series of arrays, or as a
> combination of a table and arrays. For example, when geolocation is
> provided in Time/Location form, it is permissible to store values for
> Latitude and Longitude at every (Track, Cross-Track) grid location in
> two 2D arrays  one for Latitude and one for Longitude  and also a
> Date/Time value for every scan line or point, as one 1D or 2D table,
> respectively.
>
> Table 2-4 summarizes these possible components of a swath. A
> particular swath may have multiple instances (or no instances) of any
> of these different components except the geolocation objects; there
> cannot be more than one geolocation table; and the number of
> geolocation arrays in a single swath should be kept to a minimum
> (having one table *and* several arrays is permissible).

##  {#section-2 .unnumbered}

[]{#__RefHeading___Toc455896292 .anchor}Table 2-4. Possible Components
of a Swath Structure

  ------------------------- -------- ------------------------------------
  Component Type            Dim.     Comments

  Data Field                nD       Scalar values per Track entry

  2D Data Array (scanner)   2D       Scan Lines per Track entry

  2D Data Array (profiler)  2D       Profiles per Track entry

  3D Data Array (scanner)   3D       Multiple Scan Lines per Track entry

  3D Data Array (profiler)  3D       Multiple profiles per Track entry

  Geolocation Field         1D/2D    Date/Time, scan number, Lat/Lon,
                                     attitude, position, Track counter,
                                     etc.

  Geolocation relationships N/A      Relationship between the data and
                                     the geolocation information
  ------------------------- -------- ------------------------------------

##  Defining a Swath

> The swath structure has been created to make it possible to provide
> services on the swath that are instrument independent. For example,
> subsetting and subsampling by geolocation can be provided for data
> stored in a swath structure, independent of the instrument and product
> that the data represent. Of course, the same services *could* be
> provided even if the data were not stored according to the swath
> conventions. However, the code to supply those services would have to
> be custom-written for every instrument product.
>
> These services all revolve around geolocation information (date, time,
> latitude, longitude, etc.). The primary specifications for the swath
> structure must describe what information content is needed to permit
> derivation of geolocation. The format, dimensionality, and the
> relationship between other data arrays and the geolocation table
> and/or array(s) must be specified as well.

###  {#section-3 .unnumbered}

### Sensor Data

> The sensor data, which are the direct instrument measurements from
> which information about the Earth can be derived, are the major
> component of the swath data. The nature of the measurement may vary
> from instrument to instrument. Normally, sensor data will be processed
> by scientific algorithms for retrieving useful information. The sensor
> data, as stored in digital form, have the following properties:

1.  Data type. Examples are

-   ASCII representation of numerical values

-   8, 16, 32 and n-bit (n\>0) binary integers.

-   32 and 64 bits binary floats

2.  Data structure. The actual data can be stored in tables or
    multidimensional arrays in the swath.

3.  Data unit. Examples are

-   digital numbers (DN) read from the sensor unit,

-   a physical unit, e.g., wind speed in m/s,

-   a transformed value of a physical unit, or

-   a transformed value of the sensor digital numbers

> Transformed values are sometimes used in order to use storage space
> more efficiently. Sometimes the physical values or sensor numbers are
> not stored in the actual physical units or count values but may be
> transformed in order to provide a more convenient numerical range for
> storage. In this case, the transformation function and coefficients
> required to transform from the units of the stored data back to the
> actual physical units or sensor numbers must be provided.

### Defining Geolocation

> In a swath structure, one or more of the following methods must be
> used to provide geolocation information:

-   Time/Location

-   Analytic fit

-   Attitude/Ephemeris data for spacecraft or airborne platforms

> The data provider should consult prospective data users when selecting
> the method or methods used to provide geolocation information. For
> example, for cloud studies where the areas of surfaces or volumes of
> observed elements must be known, enough information must be provided
> to allow the user to calculate the viewing geometry. Rueden (1998)
> discusses which information should be provided with satellite data in
> order to make the data most useful.

#### 2.3.2.1 Time/Location Method {#timelocation-method .Style-4}

> When geolocation information for a swath structure is provided in
> Time/Location form, at least one of the following geolocation
> parameters must be provided:

-   *Date/Time*

-   *Latitude* and *Longitude* pairs

-   *Colatitude* and *Longitude* pairs

> Some combinations of *Date/Time*, *Longitude*, and either *Latitude*
> or *Colatitude* are allowed in a swath. This standard also allows data
> producers to add geolocation information in addition to that listed
> above into a swath.
>
> Figure 2-5 shows a geolocation table that contains Date/Time,
> Latitude, and Longitude columns for geolocation information for each
> scan line.

![](media/image7.wmf)

[]{#__RefHeading___Toc455899754 .anchor}Figure 2-5. Geolocation Table
with 1D Geolocation Information Included

> Where geolocation information exists for multiple locations in a scan,
> then the Date/Time, Latitude, and Longitude arrays should be
> two-dimensional. Figure 2-6 shows two 2D arrays of Latitude and
> Longitude, which for convenience have been combined into a single 3D
> array. Geolocation information is not required for every scan. Having
> geolocation information only in one of every several scans is
> permissible.

![](media/image8.wmf){width="2.935416666666667in"
height="2.1284722222222223in"}

[]{#__RefHeading___Toc455899755 .anchor}Figure 2-6. Geolocation Array
containing Latitude and Longitude planes

#### 2.3.2.2 Analytic Fits {#analytic-fits .Style-4}

> When the geolocation information is presented in the form of a
> function that gives latitude or colatitude and longitude as a function
> of data array index coordinates (Cross-Track and Track), the required
> information depends on the form of the function. The function may be a
> polynomial or some other function of the coordinate array position
> (*x*,*y*).
>
> If the function is a polynomial, then the latitude may be written as
>
> ![](media/image9.wmf){width="1.3041666666666667in"
> height="0.37916666666666665in"}
>
> and the longitude as
>
> ![](media/image10.wmf){width="1.3791666666666667in"
> height="0.37916666666666665in"}
>
> where the *x* and *y* represent the 'Cross-Track' and 'Track' pixel
> index numbers, respectively. The geolocation information should state
> that the functional fit is to a polynomial and give the values of the
> *a~mn~* and *b~mn~ **.***

###  {#section-4 .unnumbered}

> When the geolocation information uses other functional forms, then the
> form of the function, definitions of any coefficients of terms, and
> the values of those coefficients should be provided.

#### 2.3.2.3 Attitude/Ephemeris Data {#attitudeephemeris-data .Style-4}

> When attitude and ephemeris data are provided for a swath structure
> describing measurements from satellite or airborne platforms, the
> following information is required to enable the user to calculate both
> geolocation and viewing geometry for the measurements:

-   Date/Time

-   Platform attitude roll, pitch, and yaw angles (*ξ~r~* , *ξ~p~ ,
    ξ~y~* )

-   Platform position vector (*x*,*y*,*z*)

> The data set may provide the platform attitude and position
> information directly or it may contain other information from which
> attitude and position can be calculated.
>
> The following information is optional:

-   Platform velocity vector (*u*,*v*,*w*)

> The velocity vector may be calculated from successive values of
> position vector and time and thus need not be provided explicitly.
> This standard also allows data producers to add geolocation
> information in addition to that listed above into a swath. Other
> information used in the process of converting from focal plane
> coordinates to latitude and longitude, such as transformations from
> individual component coordinate systems to instrument (along-track,
> -scan, nadir) coordinates or instrument to platform coordinates is
> normally provided separately, usually as part of the metadata, if it
> does not vary during the flight. It may be added to the geolocation
> information if it does vary.
>
> ![](media/image11.wmf){width="4.5in" height="2.8in"}

[]{#__RefHeading___Toc455899756 .anchor}Figure 2-7. One-dimensional
Attitude/Position Geolocation Table

Figure 2-7 shows a geolocation table that contains Date, Time, and three
columns each for Attitude (*ξ~r~*, *ξ~p~ ξ~y~*) and Position (*x*, *y*,
*z*) for deriving geolocation information for a scan.

Where multiple sets of attitude and position information are available
for a scan, then the Date/Time, Attitude, Position, and Velocity arrays
should be two-dimensional. Figure 2-8 shows six 2D arrays of Attitude
and Position components, which for convenience have been combined into a
single 3D array. Geolocation information is not required for every scan.
Having geolocation information only in one of every several scans is
permissible.

![](media/image12.wmf)

[]{#__RefHeading___Toc455899757 .anchor}Figure 2-8. Geolocation Array
containing Attitude and Position planes

### The Relationship between Geolocation and Sensor Data

> The next step is to relate geolocation and sensor data by mapping the
> dimensions of the data elements to the 'Track' and 'Cross-Track'
> dimensions of the geolocation parameters. Two items must be defined:

1)  Dimension definition: Defines a dimension of geolocation data or
    sensor data. It is mandatory for each dimension in both geolocation
    data and the sensor data. The dimension definition consists of two
    parts:

-   Dimension Name: The name of a dimension. The name could be a string
    of up to 256 ASCII characters.

-   Dimension Size: The size of a dimension. It should be encoded in
    either binary or ASCII integers

.

2)  Dimension mappings. The dimension mapping defines the relationship
    between geolocation dimensions and the data dimensions. A dimension
    mapping should consist of the following four parts:

-   Data Dimension: the name of the dimension of the data object being
    mapped.

```{=html}
<!-- -->
```
-   Geolocation Dimension: the name of the dimension of the geolocation
    object to which the data object is being mapped.

```{=html}
<!-- -->
```
-   Offset: if positive, the index number along Data Dimension of the
    point in the data array where the first geolocation value applies.
    If negative, the index number along Geolocation Dimension of the
    point in the geolocation array where the first data value applies,
    which is useful in cases where the geolocation object is larger than
    the data object.

```{=html}
<!-- -->
```
-   Increment: if positive, the increment along Data Dimension for which
    there is geolocation data in the Geolocation object; if negative,
    the increment along GeoDimension at which there are data points[^1],
    which is useful in cases where the geolocation object is larger than
    the data object.

> This standard does not specify how the mappings are encoded.The
> encoding standard corresponding to this content standard will specify
> an encoding method. Appendix C (informative) of this standard gives
> some examples on how to use Object Description Language (ODL) to
> encode the relationship between geolocation and sensor data. Those
> examples are based on the current NASA EOSDIS standard for swath data.

#  References

Di, L. and Carlisle, C., The Proposed FGDC Content Standard for Remote
Sensing Swath Data. Proceedings, ASPRS/RTI 1998 Annual Conference,
Tampa, Florida.

FGDC, 1997. FGDC Standards Reference Model.
http://www.fgdc.gov/standards/refmodel.pdf

FGDC, 1999. Spatial Data Transfer Standard (SDTS) Part 5: Raster Profile
and Extensions, FGDC-002.5-1999, 58 pp.

FIPS Publication, 1994, Spatial Data Transfer Standards, FIPSPUB 173-1,
U. S. Department of Commerce, Technology Administration, National
Institute of Standards and Technology, U. S. Government Printing Office,
Washington, D. C.

HAIS, 1995. The HDF-EOS Swath Concept, White Paper 170-WP-005-001.
<http://edhs1.gsfc.nasa.gov/waisdata/docsw/pdf/wp1700301.pdf> .

RSC, 1999a . HDF-EOS Library User's Guide for the ECS Project, Volume 1:
Overview and Examples, Technical Paper 170-TP-500-001
<http://edhs1.gsfc.nasa.gov/waisdata/sdp/pdf/tp17050001.pdf> .

RSC, 1999b. SDP Toolkit User's Guide for the ECS Project,
333-CD-003-003.
<http://edhs1.gsfc.nasa.gov:8001/waisdata/toc/cd33350001toc.html> .

Rueden, J. 1998. Satellite Data Information Content, White Paper,
University of Wisconsin

#  {#section-5 .unnumbered}

# Appendix A (Normative) - Glossary OF TERMS AND ACRONYMS {#appendix-a-normative---glossary-of-terms-and-acronyms .unnumbered}

CEOS − Committee on Earth Observation Satellites.

Channel − A wavelength position or range.

Colatitude - Distance, in degrees, from the nearest pole.

Cross-track − The on-ground dimension perpendicular to the track
dimension.

Data dimension − The name of the dimension of a data object being mapped
to geographic location.

Dimension name − An identifier assigned to a particular dimension.

Dimension size − The number of points in a given dimension.

Dimension Map − The data object describing a mapping between data and
their geographic location.

Dwell − Instantaneous field of view.

EOS − Earth Observing System.

EOSDIS − Earth Observing System Data and Information System.

ESDIS − Earth Science Data and Information System.

FGDC -

Geolocation − Geographic location.

Geolocation dimension −The name of the dimension of geographic location
to which the dimension of a data object is being mapped.

HAIS − Hughes Applied Information Systems.

Increment − If positive, the interval in positions along the geolocation
dimension at which there are data; if negative the interval in positions
along the data dimension at which there are geolocation data.

Interuse − Use of the same data by different installations and systems.

ISO - International Organization for Standardization

NASA − National Aeronautics and Space Administration.

NSDI − National Spatial Data Infrastructure.

Platform - The spacecraft or aircraft carrying an instrument.

RSC - Raytheon Systems Corporation

SDP − Science Data Production.

SDTS − Spatial Data Transfer Standard.

Staring − Observation at a single geographic location.

Subsample − Data selected from a larger data set by including only those
positions at a specified interval.

Subset − Data selected from a larger data set by including only those
positions within a limited range of geographic location.

Swath − The pattern formed by one or more scans perpendicular to a
track..

TRMM − Tropical Rainfall Measuring Mission.

Track − The path of a moving point, along which time or a time-like
variable increases or decreases monotonically.

# Appendix B (Informative) - Examples of Dimension Mappings Encoded with ODL {#appendix-b-informative---examples-of-dimension-mappings-encoded-with-odl .unnumbered}

In the NASA EOSDIS standard, the mapping of data to geolocation is
described in a block of ODL text that is associated with the swath
structure itself.

For example, consider two 2D arrays, one a geolocation array
(containing, say, latitude), the other a data array (containing, say,
temperature). The following segment of ODL text defines these two arrays
and their dimensions (section 4.4.2 discusses details of this code):

Example:

object = Dimension

Name = \"GeoTrack\";

Size = 1200;

end_object;

object = Dimension

Name = \"GeoCrossTrack\";

Size = 200;

end_object;

object = Dimension

Name = \"DataX\";

Size = 600;

end_object;

object = Dimension

Name = \"DataY\";

Size = 200;

end_object;

object = GeoParameter

Name = \"Latitude\";

DataType = float32;

Dimension = \"GeoTrack\";

Dimension = \"GeoCrossTrack\";

end_object;

object = DataParameter

Name = \"Temperature\";

DataType = float32;

Dimension = \"DataX\";

Dimension = \"DataY\";

end_object;

Now, the next step is to define the relation between the data array and
the geolocation array. To do so, another ODL entry, DimensionMap, is
created. The ODL code below shows a template for this entry.

Template:

object = DimensionMap

DataDimension = \<dimension name\>;

GeoDimension = \<dimension name\>;

Offset = \<value\>;

Increment = \<value\>;

end_object;

A DimensionMap entry is interpreted as follows:

• DataDimension is the name of the dimension of the data object being
mapped.

• GeoDimension is the name of the dimension of the geolocation object to
which the data object is being mapped.

• Offset: if positive, the index number along Data Dimension of the
point in the data array where the first geolocation value applies; if
negative, the index number along GeoDimension of the point in the
geolocation array where the first data value applies, which is useful in
cases where the geolocation object is larger than the data object.

• Increment is, if positive, the increment along DataDimension for which
there is geolocation data in the Geolocation object; if negative, the
increment along GeoDimension at which there are data points[^2] , which
is useful in cases where the geolocation object is larger than the data
object.

So for the example of the two arrays used in this section, we would need
the following two DimensionMap entries:

ODL Code Example:

object = DimensionMap

DataDimension = \"DataX\";

GeoDimension = \"GeoTrack\";

Offset = 0;

Increment = -2;

end_object;

object = DimensionMap

DataDimension = \"DataY\";

GeoDimension = \"GeoCrossTrack\";

Offset = 0;

Increment = 1;

end_object;

In the example ODL code above, a value for Increment of -2 in the first
DimensionMap means that the Latitude array advances two entries along
the GeoTrack dimension for every one entry of the Temperature array.
Note that the negative is used to designate that the geolocation array
is larger than the data array. In the second DimensionMap, a value for
Increment of 1 means that the DataY and GeoCrossTrack dimensions are the
same size, and map one-to-one.

In cases where a data object and a geolocation object share the same
dimension, the relationship can be assumed to be a one-to-one mapping,
and there is no need to explicitly define it with a DimensionMap entry.

# Appendix C (INFORMATIVE) - An Example Swath {#appendix-c-informative---an-example-swath .unnumbered}

This section walks through an example swath to illustrate the concepts
discussed in this standard. Consider Figure C-1, which is a
representation of a swath consisting of a 3D data array, a series of 2D
geolocation arrays, and a single, 1D geolocation table. Data are
available at 600 points along the track. Each point can be identified by
a date and time of measurement. For each point along the track, there
are 1000 cross-track measurement points across it; geolocation for these
points is given by two 600x1000 geolocation arrays, one for latitude and
one for longitude, which are combined into a single array. The data are
temperatures at 10 different altitudes and are contained in a
600x1000x10 data array, with the dimensions corresponding to track x
cross-track x height.

![](media/image13.wmf){width="5.108333333333333in"
height="4.591666666666667in"}

[]{#__RefHeading___Toc455899758 .anchor}Figure C-1. Conceptual View of
Example Swath, with 3D Array,\
Time/Geolocation Array, and Geolocation Table.

Table C-1 lists the components.

[]{#__RefHeading___Toc455896293 .anchor}Table C-1. Components of Example
Swath.

  -------------------- ------ ---------------- ----------------------------
  Component            Dim.   Size             Comments

  Data                 3D     600\*1000\*10    Track Dimension. Always
                                               first

  Geolocation Array    3D     600\*1000\*2     Lat. and Long. combined

  Geolocation Table    1D     600              In this case, one field, but
                                               should be several columns
  -------------------- ------ ---------------- ----------------------------

ODL Code Example:

object = Dimension

Name = \"GeoTrack\";

Size = 600;

end_object;

object = Dimension

Name = \"GeoCrossTrack\";

Size = 1000;

end_object;

object = Dimension

Name = \"DataX\";

Size = 600;

end_object;

object = Dimension

Name = \"DataY\";

Size = 1000;

end_object;

object = Dimension /\* the 3rd dim. of the data array \*/

Name = \"Band\";

Size = 10;

end_object;

object = GeoParameter

Name = \"Latitude\";

DataType = float32;

Dimension = \"GeoTrack\";

Dimension = \"GeoCrossTrack\";

end_object;

object = GeoParameter

Name = \"Longitude\";

DataType = float32;

Dimension = \"GeoTrack\";

Dimension = \"GeoCrossTrack\";

end_object;

object = GeoParameter /\* the geolocation table \*/

Name = \"Date/Time\";

DataType = float32;

Dimension = \"GeoTrack\";

end_object;

object = DataParameter

Name = \"Temperature\";

DataType = float32;

Dimension = \"DataX\";

Dimension = \"DataY\";

Dimension = \"Band\"; /\* the 3rd dimension of array \*/

end_object;

object = DimensionMap

DataDimension = \"DataX\";

GeoDimension = \"GeoTrack\";

Offset = 0;

Increment = 1;

end_object;

object = DimensionMap

DataDimension = \"DataY\";

GeoDimension = \"GeoCrossTrack\";

Offset = 0;

Increment = 1;

end_object;

[^1]: A value of -n is actually meant to indicate a stride of 1/n. The
    negative value is used in order to avoid the rounding error and
    interpretation issues inherent in floating point values.

[^2]: A value of -n is actually meant to indicate a stride of 1/n. The
    negative value is used in order to avoid the rounding error and
    interpretation issues inherent in floating point values.