FGDC Document Number FGDC-STD-009-1999

**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

**11Introduction**

1.1Objective1

1.2Scope1

1.3Applicability1

1.4Related Standards1

1.5Standards Development Procedures2

1.6Maintenance Authority3

**2The Swath Concept4**

2.1What Is a Swath4

2.2The Components of a Swath8

2.3Defining a Swath9

*2.3.1Sensor Data9*

*2.3.2Defining Geolocation10*

*2.3.3The Relationship between Geolocation and Sensor Data13*

**3References15**

**Appendix A  (Normative) - Glossary OF TERMS AND ACRONYMS16**

**Appendix B (Informative) - Examples of Dimension Mappings Encoded with ODL17**

**Appendix C (INFORMATIVE) - An Example Swath20**

FIGURES

Page

4Figure 2‐1 Physical View of a Simple Swath:                                                                                                   a Time-ordered Series of Scan Lines

Figure 2‐2 Physical view of a swath derived from ground-based radar:                                                           a time-ordered series of sweeps5

Figure 2-3 Data view of a sample swath:  a time-ordered series of scalars and arrays6

Figure 2-4  Data view of a sample swath:  Attitude/ephemeris used for geolocation6

Figure 2-5.  Geolocation Table with 1D Geolocation Information Included11

Figure 2-6.  Geolocation Array containing Latitude and Longitude planes11

Figure 2-7. One-dimensional Attitude/Position Geolocation Table12

Figure 2-8.  Geolocation Array containing Attitude and Position planes13

Figure C-1.  Conceptual View of Example Swath, with 3D Array,  Time/Geolocation Array,  and Geolocation Table.20

TABLES

Page

7Table 2-1.  Dimension definitions for a generic scanning instrument

Table 2-2.  Dimension definitions for a generic profiling instrument7

Table 2-3.  Dimension definitions for a generic scanning-profiling instrument8

Table 2-4.  Possible Components of a Swath Structure9

Table C-1.  Components of Example Swath.21

# 1 Introduction

## 1.1 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.

## 1.2 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.

## 1.3 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.

## 1.4 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.

## 1.5   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.

## 1.6  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.

# 2   The Swath Concept

## 2.1   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. 

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

**

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

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

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

***Table 2-1.  Dimension definitions for a generic scanning instrument***

**Dimension**

**Description**

**Comments**

Track

Path of moving point perpendicular to which instrument scans

Mandatory

Cross-Track

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

Mandatory

Detector

Number of footprints per dwell

Optional

Band or Channel

Generally used for lower level data that have not been processed into science parameters

Optional; Band and Parameter are mutually exclusive

Parameter

No physical mapping; generally used for higher level data that have been processed into science parameters

Optional; Band and Parameter are mutually exclusive

***Table 2-2.  Dimension definitions for a generic profiling instrument***

**Dimension**

**Description**

**Comments**

Track

Path of moving point perpendicular to which instrument scans

Mandatory; must be the first declared dimension

Profile

Perpendicular to the track and in the line of sight to the Earth

Mandatory; ordering among 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 Channel

Generally used for lower level data that have not been processed into science parameters

Optional; ordering among dimensions other than Track is unimportant; Band and Parameter are mutually exclusive

Parameter

No physical mapping; generally used for higher level data that have been processed into science parameters

Optional; ordering among dimensions other than Track is unimportant; Band and Parameter are mutually exclusive

***Table 2-3.  Dimension definitions for a generic scanning-profiling instrument***

**Dimension**

**Description**

**Comments**

Track

Path of moving point perpendicular to which instrument scans. 

Mandatory

CrossTrack

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

Mandatory

Profile

Perpendicular to the track and in the line of sight to the Earth

Mandatory; equivalent to atmospheric level

Detector

Number of foot prints per dwell

Optional

Band or Channel

Generally used for lower level data that have not been processed into science parameters

Optional; Band and Parameter are mutually exclusive

Parameter

No physical mapping; generally used for higher level data that have been processed into science parameters

Optional; Band and Parameter are 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. 

## 2.2   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).

***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

## 2.3 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.

### 2.3.1 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. 

### 2.3.2 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.1Time/Location Method***

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.

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

***Figure 2-6.  Geolocation Array containing Latitude and Longitude planes***

***2.3.2.2 Analytic Fits***

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 

and the longitude as 

 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*amn* and  *bmn**.***

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***

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.  

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

***Figure 2-8.  Geolocation Array containing Attitude and Position planes***

### 2.3.3 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.

· Geolocation Dimension: 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 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.

· 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, 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.

# 3 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

# Appendix A  (Normative) - Glossary OF TERMS AND ACRONYMS

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

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

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.

***Figure C-1.  Conceptual View of Example Swath, with 3D Array, Time/Geolocation Array,  and Geolocation Table.***

Table C-1 lists the components.

***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;

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

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

PAGE  

**_________________________________________________________________________________________________________**

Federal Geographic Data Committee

 Department of Agriculture ( Department of Commerce  ( Department of Defense ( Department of Energy 

Department of Housing and Urban Development ( Department of the Interior ( Department of State

Department of  Transportation ( Environmental Protection Agency

Federal Emergency Management Agency ( Library of Congress

National Aeronautics and Space Administration ( National Archives and Records Administration

Tennessee Valley Authority

# _972718857.doc

# _973082611.doc

# _995188047.doc

# _995459519.doc

# _972997413.doc

# _962203720.doc