The Generalized Satellite Format (GSF) is the core data format for IVICS and all of the GSF programs. The GSF library provides data creation and access functions for GSF files.
"Standard" formats such as HDF, netCDF, etc. were considered for use as the "IVICS" format. After weighing the pros and cons of the various formats, it was decided that none of them really provided the level of flexibility and efficiency needed for the project. The decision was made to create a custom format which could be designed to fit efficiently into the code framework. GSF evolved as the code itself was being developed. This allowed the format to be adapted to fit the most common access methods needed by the programs.
There are three common access modes used with satellite data:
1. Read all bands for a given pixel (x,y location). Store as Band interleaved by pixel (BIP)
2. Read all pixels for a give band. Store as band sequential (BSQ)
3. Read all pixels and all bands for a given line of data. Store as Band interleaved by line (BIL)
GSF uses a modified band interleaved by line (BIL) format. BIL provides random spatial access allowing any line of data to be read from a file. Since all of the channels of each pixel for a given line are read, it provides some of the benefit of BIP format as well. BIL format was selected for GSF because it provides the best trade-off between amount of data in memory and ease of random file access.
The most frustrating aspect (IMHO) of dealing with satellite data is the multitude of data formats. Every satellite data format is different. Even if a data file is in a so-called standard format (HDF, netCDF, HDFEOS) you still need a custom reader to access the data. Creating those readers is somewhat tedious process. We have managed to accumulate a number of readers for various satellite formats and have provided them with the IVCIS software.
In order to make IVICS work with any type of satellite data, we needed to create a data mode which provided all of the information necessary to represent the satellite data in a "generic" way.
A GSF file has the following basic structure:
Each GSF file consists of a GSF file header and 1 or more components. A GSF file containing more than one component is called a composite GSF file. Each component contains one or more channels of data. All components in a GSF file must register with each other spatially. However, the components may be of different spatial resolutions from each other. For example, data from MODIS, ASTER, and several others are composed of channels with different spatial resolutions. Each of the GSF components must contain channels of the same spatial resolution. In the case of MODIS, the first component is composed of channels 1 and 2 at 250m resolution, channels 3-7 are in component 2 at 500m, and the remaining channels are in component 3 at 1000m resolution. Each component is considered a self contained entity, and does not depend upon the presense of any other component in the GSF file. However, some of the GSF programs (i.e. gsf_class) may require that certain channels are present in a certain order within the GSF file. Special channel requirements are documented for the individual programs which need them.
When accessing a GSF file using the GSF library (or IVICS), if the file contains more than one component, one of them must be specified as the base component. The GSF file header specifies a default base component which may be overridden by the user. The GSF file is automatically accessed at the spatial resolution of the base component. This means that channels are subsetted or supersampled to the specified spatial resolution. This takes place automatically and transparently.
Each component of a GSF file contains the following file structure:
|
Field |
Description |
|
Data Type |
Internal code indicating data type (MODIS, AVHRR, etc.) |
|
Year |
|
|
Julian Day |
0 - 365 |
|
Satellite number |
Valid for certain sensors ( i.e. 9 for NOAA - 9) |
|
Version number |
Version of GSF format (provides backward compatibility if format changes) |
|
Pixels per line |
Width in pixels of a single scan line |
|
Spatial resolution |
Nominal pixel resolution in meters |
|
Num Nav Points |
Number of navigation (latitude, longitude) points in each line. Often navigation points are subsampled and must be interpolated |
|
Nav Point Interval |
Interval of pixels between each navigation point |
|
Start Nav Point |
Starting pixel for first navigation point in scanline |
|
|
|
|
|
|
|
|
|
More to come...
This site is under construction. Please be patient ;-)