This chapter describes the formats of the data files developed for applications running under McIDAS-X. The data files are presented alphabetically with the following information:
This chapter describes these file formats:
Area (image) files, where nnnn is a user-defined number.
In McIDAS-X, images are stored in binary files called areas. Each area file is a collection of information that defines the image and its associated ancillary data.
Area files are usually named AREAnnnn, where nnnn is a four-digit number between 0000 and 9999. This number is called the area file number. For example, AREA0013 is the name of the file containing area 13.
Areas do not have to follow this standard naming convention. The file masking option of DSSERVE may be used to access a data file of any name through the ADDE.Area files consist of these six blocks:
Some blocks also contain satellite-specific information, which is located in the Image-specific characteristics section. For area file Application Program Interfaces (APIs), refer to the API functions list.
|
For more information about reading, writing and deleting image data, see the section titled Image data in Chapter 5, Accessing Data . |
The first 64 words of an area file contain the directory block for the image. The directory lists ancillary information about the image, such as the number of lines and data points per line, the satellite ID and the number of spectral bands. The data in the directory is stored as 32-bit (4-byte) twos- complement binary integers or as ASCII characters.
Each of the directory's 64 words is described below. Since some of the words are satellite specific, see the section titled Image-specific characteristics that follows. All byte offsets and pointers are zero-based. Note that all data shown as yyyddd are the year and day-of-year. The yyy values are the actual year modulo 1900.
|
Word |
Description |
|---|---|
|
actual image start time, hhmmss; in milliseconds for POES data |
|
|
For more information about image data, see the section titled Image data in Chapter 5, Accessing Data. For more information about coordinate systems, see the section titled Coordinate systems in Chapter 2, Learning the Basics . |
The navigation (NAV) block contains the information for determining the location of data points in physical space. Word 35 of the directory block contains the byte offset to the start of the navigation block. If an image isn't navigated, word 35 is zero. The NAV block format varies with each satellite; see the section titled Image-specific characteristics that follows.
The calibration (CAL) block contains information for converting image data from its stored (internal) units to more meaningful units such as radiance or albedo. The presence of this block depends on the implementation of the satellite-specific calibration. Word 63 of the directory block contains the byte offset to the start of the calibration block. If there is no CAL block, word 63 is zero. The calibration block format varies with each satellite; see the section titled Image-specific characteristics that follows.
The supplemental (or auxiliary) block contains additional information that is specific to a data type. For example, information specific to radar data is stored in this block. Also, the latitude/longitude grid for the LALO navigation is stored in this block. Word 60 of the directory block contains the byte offset to the start of the supplemental block. Word 61 contains the total number of entries in the supplemental block. If there is no supplemental block, words 60 and 61 are zero.
The data block contains the actual image data values. Any data point in an image or image sector can be located with image and file coordinates.
An area file may be produced from an image by sampling or averaging the data. In the case of multiband images, the file may include only a portion of the measured spectral bands, so that each element contains fewer data values than are contained in the original image. To map an area back to the original image, these two formulas are used:
Image Line = UpperLeftLine + (File Line * LineResolution)
Image Element = UpperLeftEle + (File Element * ElementResolution)
UpperLeftLine is the line coordinate of the first image line and UpperLeftEle is the element coordinate of the first image element. File Line and File Element are zero-based.
When LineResolution and ElementResolution are both 1, the image resolution is 1, or full resolution. If the image resolution is 4, every fourth line and element of an image originally at resolution 1 are included in the image. Each sensor has its own scan resolution, so an image resolution of one will mean different geographic resolutions from one satellite to another.
Each line is divided into two parts: the line prefix and the actual data values as shown below. The line prefix contains information about the image and the particular line.
line prefix 1 line data 1 line prefix 2 line data 2 etc.
|_____________|___________|_____________|___________|___...
0 byte numbers increase >>
Although the size and content of the line prefix depend on the image source defined in word 52 of the directory block, each line in an image has the same prefix length. Word 15 of the directory block contains the length of the line prefix, in bytes. If no line prefix exists, word 15 is zero.
The line prefix may contain any region shown in the diagram below and described in the following table; the regions' lengths are multiples of four bytes.
validity code documentation calibration band list
|______________|_______________|_____________|___________|
0 byte numbers increase >>
Word 34 of the directory block contains the byte offset to the start of the data block. Each line in an image is the same length and a multiple of four bytes. To calculate the length of a line prefix, the line data, or the entire data block, use the formulas below.
line prefix length = doc + cal + band + 4 (if valcode is present)
line data length = nbands*nele*nbytes
line length = line prefix length + line data length
data block length = nlines * line length
The parameters used in these formulas are defined in the directory block and provided in the table below.
|
Parameter |
Directory block word |
Definition |
|---|---|---|
|
length of the prefix validity code; if nonzero, the length is four bytes; otherwise it is zero |
||
An area file may contain a comment (AUDIT) block containing a variety of textual information such as a list of commands run on the image object to date. Each comment record is 80 ASCII characters. Word 64 of the directory block contains the number of comment records, or cards.
TIP (TIROS-N Information Processor) data is extracted from the AVHRR, GAC and LAC data described in the previous section. TIP data also contains information received from the MSU (Microwave Sounding Unit), the HIRS (High Resolution Infrared Sounder), and the SSU (Stratospheric Sounding Unit). These three sources measure incoming radiation in the infrared and microwave spectrum.
The navigation block for TIP data is filled with zeros; no calibration information is needed.
TIP data is transmitted as 10 bits and stored as 16 bits. The 10-bit data is formatted as follows, with x representing a data bit and the rest being zero-filled after shifting: | 0 | x | x | x | x | x | x | x | x | x | x | 0 | 0 | 0 | 0 | 0 |
The line prefix for the data block contains the information below.
|
Region |
Description |
|---|---|
|
optional, but recommended to flag missing data, which requires zeros as placeholder data or a validity code that does not match the value in the area directory |
|
The following section describes the navigation and calibration for the visible and infrared channels of the Geostationary Meteorological Satellites, GMS-4 and GMS-5. GMS-4 has one channel of visible and one channel of infrared data. GMS-5 has two channels for visible and two channels for infrared data; only one channel of each is used. The remaining two channels are reserved for backup.
|
For a complete description of the line documentation fields, see NOAA Technical Memorandum NESS 107 , 1988. The band information for TIP data is provided in this manual in Appendix B, Image Information. |
|
|
The tables referenced in this section are from the document Revision of GMS Stretched-VISSR Data Format , Japan Meteorological Agency, October 1993. |
The following three tables list the words used in the GMS navigation block. These are 1-byte words. The first table lists all the words in the GMS navigation block and the following two tables list the words used in the attitude prediction data sub-blocks and the orbit prediction data sub-blocks.
The Type column in the tables below shows scaled integers in the format R*M.N. The R indicates real numbers, M is the number of bytes and N is the exponent.
|
The GMS data is also formatted using the navigation block format of GOES-7 data. The section GOES-7 AAA navigation block describes the GOES-7 navigation block. |
The table below describes an attitude data prediction sub-block. The GMS navigation block contains ten attitude data prediction sub-blocks that occupy words 257-617. Each block occupies 36 words.
The table describes the orbit prediction data sub-block. The GMS navigation block contains eight orbit prediction sub-blocks that occupy words 618-2352. Each block occupies 182 words.
The GMS calibration block contains both directory and data conversion tables located in sub-blocks that follow the directory. The 128-word directory block, shown below, indicates the locations of the six sub-blocks. The starting byte offset for each sub-block varies with the data; therefore, it is shown as a variable in the directory below.
|
Word |
Value |
Description |
|
Words 1 to 256 of GMS 4-or -5 calibration block; see the table below |
||
The table below describes the calibration data sub-blocks, not all of which may be filled. The calibration data, which follows the directory, has a length of 6400 bytes.
|
See table A-7 in the Revision of GMS stretched-VISSR data format document for a complete description of the data block. |
|
Byte |
Descriptions |
|---|---|
|
sub-block 2; visible level-to-albedo conversion tables; four 64-level tables for VIS1 through VIS4 detectors |
|
The prefixes for each scan line of visible data must contain a code indicating the detector used. The first four bytes of the documentation section should contain the following information.
|
Code |
Description |
|---|---|
The Defense Meteorological Satellite Program (DMSP) satellites are polar orbiting satellites. DMSP has two sensors: the Operational Linescan System (OLS) and the Special Sensor for Microwave Imagery (SSM/I) data. The following sections describe the navigation and calibration blocks for each sensor.
The table below lists the contents of the DMSP navigation block. The block contains 128 words and is used for all DMSP signal types.
|
Word |
Value |
Description |
|---|---|---|
|
right ascension of ascending node from the ASCII record below; deg*1.e6 |
||
|
argument of perigee from the ASCII record below; per,deg*1e7 |
||
The DMSP navigation block includes a 0-based, type 8 ASCII record, in words 120-127, that contains the scaled integer values used by the navigation block. The table below describes the ASCII record.
|
Character numbers |
Description |
|---|---|
The OLS and microwave sensors use different calibration. The OLS calibration uses only one pair of of gain and offset parameters to transform infrared pixel values to radiance. The offset is set to 190.0 and the gain is set to .4706. The calibration module kbxols.dlm contains the offset pair. The visible pixels are not calibrated.
For the microwave sensors, each data line is calibrated and the information is stored in the documentation section. A postprocessor, DMSPCAL, calculates the gains and offsets from the information in the documentation section. The table below describes the calibration documentation for each line of data.
When DMSPCAL is run, a gain and offset for each channel is placed in the calibration section of each scan line prefix. The table below describes the byte location of each gain and offset pair.
|
Bytes |
Description |
|---|---|
|
Word |
Description |
|---|---|
|
2 |
image line of the North Pole |
|
3 |
image element of the North Pole |
|
4 |
standard latitude 1, DDDMMSS |
|
5 |
standard latitude 2, DDDMMSS |
|
6 |
spacing at standard latitude, M |
|
7 |
normal longitude, DDDMMSS |
|
8 |
radius of the planet, M |
|
9 |
eccentricity of the planet, x1000000 |
|
10 |
coordinate type, &ge 0 planetodetic, < 0 planetocentric |
|
11 |
longitude convention, &ge 0 west positive, < 0 west negative |
|
12-120 |
reserved |
|
121-128 |
memo entry; up to 32 characters of comments |
|
Word |
Description |
|---|---|
|
2 |
image line of the equator |
|
3 |
image element of the equator |
|
4 |
standard latitude |
|
5 |
spacing at standard latitude, meters |
|
6 |
normal longitude, DDDMMSS |
|
7 |
radius of the planet, M |
|
8 |
eccentricity of the planet, x1000000 |
|
9 |
coordinate type, &ge 0 planetodetic, < 0 planetocentric |
|
10 |
longitude convention, &ge 0 west positive, < 0 west negative |
|
11-120 |
reserved |
|
121-128 |
memo entry; up to 32 characters of comments |
|
Word |
Description |
|---|---|
|
1 |
PS |
|
2 |
image line of the North Pole |
|
3 |
image element of the North Pole |
|
4 |
standard latitude, DDDMMSS |
|
5 |
spacing at standard latitude, M |
|
6 |
normal longitude, DDDMMSS |
|
7 |
radius of the planet, M |
|
8 |
eccentricity of the planet, x1000000 |
|
9 |
coordinate type, &ge 0 planetodetic, < 0 planetocentric |
|
10 |
longitude convention, &ge 0 west positive, < 0 west negative |
|
11-120 |
reserved |
|
121-128 |
memo entry; up to 32 characters of comments |
|
Word |
Description |
|---|---|
|
2 |
row (image coordinates) of the radar site |
|
3 |
column (image coordinates) of the radar site |
|
4 |
latitude of the radar site, DDDMMSS |
|
5 |
longitude of the radar site, DDDMMSS |
|
6 |
pixel resolution, meters |
|
7 |
rotation of north from vertical, degrees x1000 |
|
8 |
if present, same as 6, but only for longitude direction |
|
Word |
Description |
|---|---|
|
2 |
a particular image row number |
|
3 |
latitude corresponding to word 2, degrees x10000 |
|
4 |
a particular image column number |
|
5 |
longitude corresponding to word 4, degrees x10000 |
|
6 |
latitude degrees/image line, degrees x10000 |
|
7 |
longitude degrees/image line, degrees x10000 |
|
8 |
radius of the planet, meters |
|
9 |
eccentricity of the planet, x1000000 |
|
10 |
coordinate type, &ge 0 planetodetic, < 0 planetocentric |
|
11 |
longitude convention, &ge 0 west positive, < 0 west negative |
Schema definition files are ASCII text files that contain lines of text defining the structure of MD files for point-source data types. To create a schema definition file, use a standard editor to enter a set of text lines. The file serves as input to the schema registration program, SCHE, that reads the text lines and forms a blueprint of the MD file's structure. SSEC distributes the schema definition files below with every McIDAS upgrade.
|
Schema file |
Contents |
|---|---|
Because schema definition files form the input to an application, you must use the formats provided below for each text line of a schema file.
A header is required for each schema definition file. Its format is shown below, followed by a table of parameter definitions.
|
Parameter |
Definition |
|---|---|
Either a row header or a column header is required for each schema definition file. The row and column header formats are shown below, followed by a table of parameter definitions.
ROWS nrows "description
rkeyname1 rscale1 runits1 "description
...
rkeynameN rscaleN runitsN "description
|
Parameter |
Definition |
|---|---|
COLUMNS ncols "description
ckeyname1 cscale1 cunits1 "description
...
ckeynameN cscaleN cunitsN "description
|
Parameter |
Definition |
|---|---|
Repeat groups are optional. They are useful when data of the same type is repeated within the data portion of a record. The format is shown below.
|
Parameter |
Definition |
|---|---|
|
number of repeat groups in the data portion of the schema definition |
|
To end the schema definition file, use ENDSCHEMA . To enter comments, use the format "comments.
No API functions exist for reading and writing MD schema definition files.
|
For more information about MD file schemas and associated terminology, see the MDXXnnnn data structure in this chapter. |
Enhancement save files, where * is a user-defined file name.
Enhancement save files are binary files, each containing an 817-word (3268-byte) table. Words 2 through 768 contain the red, green and blue color intensities for each of the possible 256 brightness values. The individual intensities have a physical range of 0 to 255, where 0 is the minimum and 255 is the maximum intensity.
Currently, no API library functions exist for reading or writing enhancement save files.
The panel configuration file is a binary file that describes the layout of the panels for each image frame. If it is not present, all frames are single-paneled (i.e. full screen). There are two bytes per frame, one for the number of panels in the x-direction and one for the number of panels in the y-direction. Up to 127 panels in each axis can be defined for a single frame.
If the frame has never been paneled with the PANEL command, the two bytes contain HEX 8080. If the frame was explicitly set to 1x1 geometry, the bytes contain HEX 0101. The software considers them both to represent a single panel frame.
The frame enhancement file is a binary file that contains an 816-word
(3264-byte) table for each frame allocated for the session. To calculate the word position of a particular frame's enhancement table, use the formula below.
In each table, the first 768 words contain the red, green and blue color intensities for each of the possible 256 brightness values. The individual intensities have a physical range of 0 to 255, where 0 is the minimum and 255 is the maximum intensity.
Currently, no API library functions exist for reading and writing frame enhancement files.
Image frame files, where n is the frame number and p is the panel number.
The image frame file is a binary file that describes the contents of an image frame. For single panel (i.e. full screen) frames, y is zero. A single panel frame 1 uses file FRAME1.0; a 4-panel frame 2 uses files FRAME2.1 through FRAME2.4.
The file has three components:
The default size of the user extension is zero. The size can be modified by editing the the file m0panel.h and rebuilding McIDAS-X. No SSEC programs use the extension.
The navigation block contains the information for determining the location of the data points in physical space. The navigation block's format varies with each satellite. See the section titled Image-specific characteristics for image files (AREAnnnn).
For image frame Application Program Interfaces (APIs), refer to the API functions listing.
|
Fortran Function |
Description |
|---|---|
|
flags a frame directory or navigation block as unused (erased) |
|
GMSCAL is a binary file that contains calibration data for GMS VIS (visible) and IR (infrared) sensor data transmitted in the GMS Stretched-VISSR real-time signal.
VIS data is 6-bit. Calibration is achieved with a 64-value VIS level-albedo lookup table. This calibration table is interpolated to make a 256-value table. IR data is 8-bit. Calibration is achieved with a 256-value IR level- temperature lookup table, which may change with the spacecraft.
The GMS calibration file is supplied with McIDAS-X.
Some aspects of McIDAS-X area files are specific to their image type. This section describes characteristics specific to the following types:
Although the descriptions for each image type vary, most include information about the directory, data, navigation and calibration blocks.
Grid files, where nnnn is a user-defined number.
A grid file is a binary file, which may contain a user-defined maximum number of grids. By default, a grid file is created with the ability to store 159 grids unless otherwise specified.
Grid file numbers can be between 1 and 999999. If a grid file number is five or six digits, the file name begins with only GRI or GR. For example, grid file number 12345 has the file name GRI12345, but grid file number 123456 has the file name GR123456.
Grid files do not have to follow this standard naming convention. The file masking option of DSSERVE may be used to access a data file of any name through the ADDE.
The word allocation for grid files is divided into several sections below. The grid file directory is described first, followed by the grid header. The first 33 words and words 40 through 64 of the grid header are the same for all grid types; however, words 34 to 39 are specific to a particular grid type.
For grid file Applications Program Interfaces (APIs), refer to the API functions list at the end of this section.
|
Word |
Description |
|---|---|
|
word offset, from the beginning of the grid file, where grid 1 starts; if the offset is -1, no grids exist |
|
Each grid header contains 64 words. The offset of the first word in the header is defined by the word offset in Words 10 +1 through 10 + n in the grid file, where n is the grid number.
|
Header Word |
Description |
|---|---|
|
total size; rows * columns (not to exceed the value of MAXGRIDPT in g ridparm.inc) |
|
|
value of the vertical level
|
|
|
gridded variable type:
|
|
|
used if the grid parameter is a time difference or time average, hhmmss |
|
|
used if the grid parameter is a level difference or level average; values are the same as Word 9 |
|
|
grid origin; identifies the type of program that generated the grid d ata |
|
|
grid projection type:
|
|
|
varies, depending on the grid type; see the GRIDnnnn data file in Chapter 6 for more information |
|
|
reserved; filled only if the grid was created by the McIDAS-XCD GRIB decoder |
|
|
Header Word |
Description |
|---|---|
|
standard latitudes, degrees*10000; set these two equal for polar stereographic |
|
Header Word |
Description |
|---|---|
|
clockwise rotation of column 1 relative to north, degrees*10000 |
|
For more information, refer to the National Centers for Environmental Prediction Office Note 388: GRIB, Edition 1.
|
Header Word |
Description |
|---|---|
|
original geographic ID; GRIB projection number (PDS octet 7) |
|
Graphics save tables for McIDAS-X, where * is a user-defined file name.
These binary files contain a table of the red, green and blue color intensities (0 to 255) for the graphics levels on a McIDAS-X workstation. The table is of variable length, depending on the number of graphics levels allocated by the McIDAS-X session that generated the file. Use the GU application to create a McIDAS-X graphics save table.
For graphics save tables Application Program Interfaces (APIs), refer to the API functions list at the end of this section.
HIRS calibration reference parameters.
HIRS calibration reference parameters are used to compute HIRS brightness temperatures. This binary file is organized chronologically by satellite with the last record being the most recent. Each record contains
48 words.
The first record is a header record. The following records contain data. Words 0 through 39 in the data records are the coefficients of fourth degree polynomials used to convert platinum resistance thermistor count values to temperatures. The first four words in each group of eight are for the warm blackbody target, and the fifth through eighth words in each group are for the cool blackbody, which is not routinely used in the calibration process.
This file is supplied with McIDAS-X.
For HIRS calibration reference parameters Application Program Interfaces (APIs), refer to the API functions list at the end of this section.
HIRS transmittance coefficients.
HIRSTAUL is a binary file containing 506-word records provided by the sensor source. Each sensor source has 20 records:
This file is supplied with McIDAS-X.
For HIRS transmittance coefficients Application Program Interfaces (APIs), refer to the API functions list at the end of this section.
|
Function |
Description |
|---|---|
|
retrieves HIRS Planck function, solar, flux and surface temperature coefficients |
MD files, where nnnn is a user-defined number.
MD files contain data records addressed by row and column coordinates. All records in a row also share information called a row header. Similarly, all records in a column share a column header. A complete record thus consists of the row header, column header and data. The headers hold parameters common to the data records. Row headers are located in column 0; column headers are in row 0. Fields in a record are identified by 4-character names called keys. Data values are stored as integers. Each record can be up to 400 words long; individual fields in a record are one word (4 bytes) long.
The MD file structure is self-contained. All information for accessing one of these binary files exists in the 4096-word header, which contains the schema specifying the default number of rows and columns in an MD file; the composition of the row headers, column headers and data records; and the names, scale factors, and units of the keys.
A copy of the schema resides in the MD file and in the McIDAS-X disk file named SCHEMA, which contains all schemas recognized by the system. The copy held in SCHEMA serves as a blueprint for all MD files of a particular kind of data. When an MD file is created, the schema is copied from SCHEMA to the MD file header block with all appropriate modifications.
MD file numbers can be between 1 and 999999. If an MD file number is five or six digits, the file name begins with only MDX or MD. For example, MD file number 12345 has the file name MDX12345, but MD file number 123456 has the file name MD123456.
MD files do not have to follow this standard naming convention. The file masking option of DSSERVE may be used to access a data file of any name through the ADDE.
For MD file Application Program Interfaces (APIs), refer to the API functions list at the end of this section.
|
Word |
Description |
|---|---|
|
user record, MD coordinates (0,0); not described by the schema; use for storing arbitrary information |
|
The row header begins at word 4096. The row header's length in words is rows * number of keys in the row header .
Following the row header is the column header. The column header's length is columns * number of keys in the column header .
The MD data follows the column header. The data's length is rows * columns * number of keys in the data portion . Any remaining words are available for user purposes.
Words 39-42 are filled in only during the production of real-time files. When real-time file data is copied to other MD files, words 39-42 in the destination files are set to null.
MSU calibration reference parameters.
The parameters in MSUSCRPF compute MSU (Microwave Sounding Unit) brightness temperatures and check the quality of MSU data. This binary file is organized chronologically by date; the last record is the most recent. Each record contains 48 words. There may be more than one record for a particular satellite.
The first record is a header record. The following records contain data. Words 0 through 11 in the data records are the coefficients of second-degree polynomials used to convert platinum resistance thermistor resistance measurements to temperatures for the internal warm targets.
This file is supplied with McIDAS-X.
For MSU calibration reference parameters Application Program Interfaces (APIs), refer to the API functions list at the end of this section.
Base map files, where * is the map file name.
These variable-length, binary files contain the base map data for drawing graphical map outlines. The map files and their descriptions are provided in the table below.
|
Map file |
Description |
|---|---|
Words 1 to 6000 contain the directory for the line segments. Each directory block contains six words of information.
|
Word |
Description |
|---|---|
The maximum number of line segments is 1000. The number of points in a segment is limited to 3000 by the arrays in the MAP program.
Currently, no API library functions exist for reading and writing base map files. There are, however, programs in McIDAS-XRD, MAKEMAP and MAP2TEXT, that convert McIDAS map files to and from a text format.
Image annotation description file.
The satellite description text information in this binary file is displayed as text annotation when a satellite image is loaded onto a display device.
Each 80-character record contains the following:
For image annotation description file Application Program Interfaces (APIs), refer to the API functions list at the end of this section.
File size depends on the number of satellite description entries and is computed by (20*number of entries ) words. For example, two entries may look like this:
|
Columns 1 to 19 |
Column 20 |
Columns 30 and 31 |
|---|---|---|
This file is supplied with McIDAS-X.
Image channel description file.
This file contains 80 character ASCII text records describing the instrument channel information. For each satellite/instrument combination, there is an instrument description block which must conform strictly to the following format:
This file is supplied with McIDAS-X.
There is one instrument description block for each supported satellite.
For satellites that support multiple calibration types, the combination of Cal, BRes, and nnnn lines may be repeated for each calibration type.
This binary file has 7172 words and is divided into two sections.
The file division is invisible to all parts of the schedule system accessing the file via the ID number.
For scheduled McIDAS commands Application Program Interfaces (APIs), refer to the API functions list at the end of this section.
This section contains eight words for each entry (maximum of 100).
This section contains 64 words for each entry.
|
Word |
Description |
|---|---|
Meteosat PDUS images are remapped and calibrated at the ground station before the stretched signal is disseminated. This simplifies the navigation and calibration data sections. All data is eight bits; each band is stored in a separate file.
|
For more information on Meteosat labels and headers, see the EUMETSAT document Meteosat High Resolution Image Dissemination . |
The line prefix for the data block contains the information below. For the line data, each value is transmitted as eight bits and is stored west to east and north to south in the area, the opposite of how it is transmitted.
A PDUS navigation block is divided into 256 words.
|
Word |
Value |
Description |
|---|---|---|
No calibration block is needed for PDUS; the calibration information is stored in the directory block.
User Common is a block of data stored in shared memory. Its contents are lost if McIDAS-X stops; otherwise, it retains values that allow for interprocess communication of information usually related to the state of the McIDAS-X session (for example, the number of frames being viewed or the location of the cursor). UC variables with negative subscripts are carried along from the calling process through all spawned processes. UC variables with positive subscripts and UC(0) are available to all tasks that are running whether spawned or not. Words -12 to -1 contain a snapshot of the state taken just before the command begins.
For McIDAS user common Application Program Interfaces (APIs), refer to the API functions list at the end of this section.
|
Word |
Description |
|---|---|
|
second cursor state control word; bits 0-2 are not used;
|
|
|
the disk file name for the DEV=F file; on the workstation, the file descriptors for the printer or file dataset for sdest, edest and ddest, respectively |
|
|
current graphics virtual frame; if less than zero, doesn't plot |
|
|
current diagnostic message (ddest) device: 0 = suppressed;
|
|
|
current error message (edest) device: 0 = suppressed;
|
|
|
device for standard text messages: 0 = suppressed;
|
|
|
auto context table search: 0 = no keyword substitution;
|
|
|
0 = program currently running is not a macro
|
|
|
0 = program currently running is background
|
|
|
current level when starting another process: 0 = scanner;
|
|
|
0 = command was not started by the scheduler
|
|
|
project number the command runs under; may be different from the logged on project number in UC(1) |
|
|
cursor state control word:
|
|
|
graphics state control word:
|
|
|
frame state control word:
|
|
|
project number under which the current user is logged on;
|
|
|
number of lines on the screen; for terminals where all frames are the same size |
|
|
number of elements on the screen; for terminals where all frames are the same size |
|
|
0 = terminal is local ProNET; 1 = terminal is remote bisync;
|
|
|
0 = terminal is nonvideo; 1 = terminal is video;
|
|
|
flag for the E key: 0 = lat/lon are displayed in dddmmss;
|
|
|
virtual graphics state flag: 0 = doesn't write virtual graphics;
|
|
|
loop control system; consists of the LS command and the A, B, J, Y, O and L keys; images and graphics are connected to and disconnected from the loop system via UC 54 and 59;
|
|
|
1 = image frames are connected to the loop control
|
|
|
1 = image frames are visible
|
|
|
1 = graphics frames connected to loop control
|
|
|
1 = graphics frames are visible
|
|
|
cursor type: 1 = box; 2 = crosshair; 3 = box and crosshair;
|
|
|
joystick 1: 0 = disconnected; 1 = controls cursor position;
|
|
|
saved cursor type; set when word 65 = 0 to turn off the cursor |
|
|
used by the scheduler (sked); last time through all entries flag |
|
|
0 = asynchronous communication is OK
|
|
|
routing table modification flag: 0 = modified; 1 = unchanged |
|
|
communication connection state flag: 0 = no carrier;
|
|
|
mouse button status; two 2-byte integer (I* 2) values that correspond to mouse buttons 1 and 2 respectively |
|
|
mouse movement values (mickies); two 2-byte integer (I * 2) values that correspond to movement up/down and left/right respectively |
|
|
first line in the text window to display; the range is 1 to 57 |
|
|
PF key input only; nonzero means that command line text is not allowed and the user cannot change the text window; the program must change the window |
|
|
address of a memory segment used for displaying text on windows 5 through 9; each text window uses 4000 bytes; each character is represented in a 2-byte format where the least significant byte is the character displayed and the most significant byte is the color attribute |
|
|
number of commands that mctext should remember, as specified in the -ih option of the .mcidasrc file |
|
|
1 = image window should resize to the size of the current frame (Alt R) |
|
|
if nonzero, the image window should raise itself and reset the value to zero |
|
|
terminal types with variable frame sizes; line and element sizes as halfwords |
|
|
Function |
Description |
|---|---|
|
reports the state of the mouse buttons as soon as a mouse button event occurs |
|
VASTBLS is a binary file that holds the current calibration values of the temperature, brightness and radiance for all 12 channels of GOES AA satellite data. Its fixed size is 1622016 words.
The primary blocks for VASTBLS are shown below. Each block represents a table of calibrated values for each raw value.
|
Word |
Description |
|---|---|
Each primary segment contains secondary segments (12 maximum) allocated by band number. Word addresses are relative to the start of the primary segment.
|
Word |
Description |
|---|---|
Each secondary segment contains base segments allocated by the Delta-F value. This value ranges from -5 to +5, providing 11 base segments per secondary segment. Each of the word addresses below is relative to the start of the secondary segment. The values are the actual numbers used to calibrate the data.
|
Word |
Description |
|---|---|
Virtual graphics files, where nnnn is the virtual graphics number.
These variable-length, binary files contain one or more virtual graphics scenes. A scene contains graphics attribute information, such as page boundary, line width, pen position and color information.
For virtual graphics file Application Program Interfaces (APIs), refer to the API functions list at the end of this section.
Below is a description of one scene in a virtual graphics file.
Meteosat PDUS images are remapped and calibrated at the ground station before the stretched signal is disseminated. This simplifies the navigation and calibration data sections. All data is eight bits; each band is stored in a separate file.
|
For more information on Meteosat labels and headers, see the EUMETSAT document Meteosat High Resolution Image Dissemination . |
The line prefix for the data block contains the information below. For the line data, each value is transmitted as eight bits and is stored west to east and north to south in the area, the opposite of how it is transmitted.
|
Region |
Description |
|---|---|
|
24 bytes; this is a copy of the label that arrives with each subframe |
|
|
0 bytes (not used) since each band is stored in a separate area |
A PDUS navigation block is divided into 256 words.
|
Word |
Value |
Description |
|---|---|---|
No calibration block is needed for PDUS; the calibration information is stored in the directory block.
Meteosat Second Generation (MSG) images are remapped and calibrated at the ground station before the stretched signal is disseminated. This simplifies the navigation and calibration data sections. All data is sixteen bits; each band is stored in a separate file.
|
For more information on Meteosat labels and headers, see the EUMETSAT document Meteosat High Resolution Image Dissemination . |
For the line data, each value is transmitted as sixteen bits and is stored east to west and south to north in the original files.
An MSG calibration block is divided into 128 words.
|
Word |
Value |
Description |
|---|---|---|
The GVAR Imager provides two types of data:
The supplemental data is provided in Block 0, which is the GVAR Imager documentation block. Block 0 has its own directory block, validity code, documentation region and data. The GVAR Imager sensor data likewise has its own directory, data, navigation and calibration blocks. Both types of data are described below.
The OGE tables referenced in this section are from Operations Ground Equipment, Internal Specification, DRL 504-02-1 Part 1, Specification No E007020 , released February 9, 1994, Space Systems/Loral, 3825 Fabian Way, Palo Alto, California 94303-4604. That document describes data which is formatted by the ground station and then retransmitted.
|
The band information for the GVAR Imager is provided in Appendix B, Image Information. |
The GVAR Imager documentation, Block 0, contains additional control information about an image. Some of this information is also contained in the imager sensor data. For each line of GVAR Imager sensor data transmitted, one line of Block 0 documentation is transmitted and stored in a separate area. Below are the values specific to the Block 0 directory.
|
Word |
Value |
Description |
|---|---|---|
|
length of the data block line prefix documentation,
|
||
The line prefix's validity code for Block 0 is four bytes. Its documentation region is 44 bytes, consisting of the following:
|
Documentation region |
Bytes |
OGE table |
|---|---|---|
The rest of the Block 0 line contains 8040 bytes of 8-bit data. See OGE Table 3-6.
Bytes 17-24 contain the time the block was sent from the ground station.
The GOES-8 through GOES-12 satellites have two instruments: an imager and a sounder. Areas with SSEC-assigned, even-numbered sensor sources provide imager data, while odd-numbered sensor sources provide sounder data. Word 52 of the directory block contains the image source type (GVAR) for 2-byte GVAR data as it is ingested. Word 53 contains the units that data is stored in; RAW for 2-byte raw GVAR data.
Word 14 of the directory block contains the number of spectral bands present in an image. The filter band map in word 19 of the directory block describes the bands in an area. A bit is set for each band appearing in the area. The number of bands must match the value in word 14. The values specific to the sensor data's directory block are shown below.
|
Word |
Value |
Description |
|---|---|---|
|
length of the data block line prefix documentation if single band, otherwise a higher value; in bytes |
||
The GVAR Imager produces observational data for a spatial location in five spectral bands: one visible (VIS) and four infrared (IR). An image contains only one of these five bands. Word 19 in the directory block contains a band filter map indicating the area file's band.
The highest resolution for a visible image is one. It is four for an IR image, since longer wavelengths have less resolution. For a GVAR satellite, resolution one means approximately 1 km resolution at the satellite subpoint.
Each element in a GOES-8 image contains one 10-bit pixel representing raw data from the instrument. Each pixel is stored as two bytes in the McIDAS-X area file. The hardware shifts the data so the 10 bits are formatted as shown below. The x's are the data bits; the rest is 0-filled after shifting.
The sensor data's line prefix contains a 4-byte validity code and a 76-byte documentation region consisting of the following:
|
Documentation region |
Bytes |
OGE table |
|---|---|---|
|
block header CRC (the last three bits only); a bit is set if the block header copy is good; this data is usually 00,07 |
||
|
line documentation consisting of sixteen pairs of 10-bit fields, right justified; each 10-bit field can be obtained with a LOGICAL AND against 03FF |
||
The block header and line documentation blocks are included for every band in the image line.
The rest of the line consists of up to 41920 bytes of data. Since it is 2-byte data, half that many pixels are represented.
Bytes 17-24 contain the time the block was sent from the ground station.
The GVAR Imager navigation block contains 640 words. Unless otherwise noted, words are twos-complement binary integers. This navigation information comes from Block 0 records. Bytes designated R*4 in OGE Tables are in Gould format. They must be scaled and converted to integers or converted to Real on the machine doing the decoding, scaled as designated below, and then converted to integer.
|
Word |
Value |
Description |
|---|---|---|
|
imager scan status; bits 0-15 are right justified, with 15 the least significant; IMC active flag is bit 8, counting from the least significant bit; 1=active; see OGE Table 3-6, bytes 3-6 |
||
|
imager scan status; bits 16-31 are right justified, with 31 the least significant; yaw-flip processing enabled flag is bit 16, counting from the least significant bit; 1=enabled; see OGE Table 3-6, bytes 3-6 |
||
|
6 - 62
|
see OGE Table 3-6, bytes 295 - 522
|
|
|
63 - 117
|
roll attitude angle (OGE Table 3-6, bytes 523-742)
|
|
|
attitude angles
|
||
|
misalignment angles
|
||
|
nominal start time of the image; comes from Block 0 when navigation data is taken from Block 0, HHMMSSmmm |
||
|
instrument nadir, north/south cycles; see OGE Table 3-6, byte 6305 |
||
|
instrument nadir, east/west cycles; see OGE Table 3-6,
|
||
|
instrument nadir, north/south increments; see OGE Table
|
||
|
instrument nadir, east/west increments; see OGE Table 3-6, byte 6309-6310 |
||
The imager calibration block is made up of 128 words (512 bytes), as shown in the table below. The data is in the Gould format.
|
Word |
Value |
Description |
|---|---|---|
|
visible bias coefficients; one per detector (OGE Table 3-6, bytes 6399-6430) |
||
|
visible first order gain coefficients; one per detector
|
||
|
visible second order gain coefficients; one per detector (OGE Table 3-6, bytes 6463-6494) |
||
|
visible radiance to albedo conversion factor (OGE Table
|
||
|
det side 1 IR bias scaling factors; one per IR channel (OGE Table 3-6: bytes 6667-6670 Ch 4, Side 1; bytes 6675-6679 Ch 5, Side 1; bytes 6683-6686 Ch 2, Side 1; bytes 6691-6694 Ch 3, Side 1) |
||
|
det side 2 IR bias scaling factors; one per IR channel (OGE Table 3-6: bytes 6695-6698 Ch 4, Side 2; bytes 6703-6706 Ch 5, Side 2; bytes 6711-6714 Ch 2, Side 2; bytes 6719-6722 Ch 3, Side 2) |
||
|
det side 1 IR gain scaling factors; one per IR channel (OGE Table 3-6: bytes 6723-6726 Ch 4, Side 1; bytes 6731-6734 Ch 5, Side 1; bytes 6739-6742 Ch 2, Side 1; bytes 6747-6750 Ch 3, Side 1) |
||
|
det side 2 IR gain scaling factors; one per IR channel (OGE Table 3-6: bytes 6751-6753 Ch 4, Side 2; bytes 6759-6762 Ch 5, Side 2;bytes 6767-6770 Ch 2, Side 2; bytes 6775-6778 Ch 3, Side 2) |
||
The GVAR Block 11 holding areas contain data for sounder images. This data is not easily accessed. A decoder must reformat the raw Block 11 data and place it in the sounder image, where it is available for analysis and display.
|
Word |
Value |
Description |
|---|---|---|
|
number of bytes per element, depending on the element size of the band; a holding area cannot contain both 1- and 2-byte data |
||
|
block type filter; positions of set bits correspond to the block types requested; the least significant bit is the rightmost bit; the value 787968 translates to 0c0600 hex with bits set in positions 20, 19, 11 and 10 |
||
|
length of the data block line prefix documentation,
|
||
GVAR transmits 22 types of Block 11 data. This can be 6-, 8- or 10-bit data. The user can specify any type to be stored in a single holding area. Control fields in the line prefix or the first portion of the data (called the SAD ID) are used by postprocesses, such as the sounder decoder, to determine the block type. Each data block line consists of a single Block 11 sector, or block . All blocks are 8040 bytes. Refer to the OGE, sections 3.3.7 - 3.3.7.14 for a description of the contents of each block type.
The 10-bit data is formatted as follows, with x representing a data bit and the rest being zero-filled after shifting.
The 8-bit data is formatted as follows:
The 6-bit data is formatted as follows:
The line prefix for Block 11 contains a 4-byte validity code. Its documentation region is 40 bytes, consisting of the following:
|
Documentation region |
Bytes |
OGE table |
|---|---|---|
|
block header CRC; this field is overwritten in the mainframe by a 2-byte counter and is used to check sequencing of the data flow |
||
The rest of the Block 11 line consists of up to 8040 bytes of data, depending on block type.
Bytes 17-24 contain the time the block was sent from the ground station.
GVAR Sounder areas are decoded from Block 11 data. The GVAR Sounder decoder reads the Block 11 holding areas, which contain blocks of type 32 (20 hex), type 35 (23 hex) and others. These blocks are documented in OGE, sections 3.3.7.2 and 3.3.7.3.
Navigation and calibration data is read from type 32 blocks, which are sounder documentation blocks. Sensor data is read from type 35 blocks, which are sounder scan data blocks. After the sensor data is read, it is reformatted and placed in the sounder image area.
|
The band information for the GVAR Sounder is provided in Appendix B, Image Information. |
|
Word |
Value |
Description |
|---|---|---|
|
line resolution; if lines are sampled or averaged, the resolution is a multiple of 10 |
||
|
element resolution; if pixels are sampled or averaged, the resolution is in multiples of 10 |
||
|
band filter map; translates to 0007ffff hex; a bit is set for each of bands 1 - 19 |
||
|
length of the data block line prefix documentation, in bytes; if 216, the first 180 words of Sounder Auxillary Data block have been have been added |
||
|
length of the data block line prefix band list,
|
||
The GVAR Sounder produces data for a given spatial location in 18 IR spectral bands and one visible band. The number of bands in the sounder data must match the value in word 14 of the directory block. Word 19 designates the band map. All sounder data fields are 13 bits placed in 2-byte (16-bit) fields. Each data point in a scan data block has 23 bands of data. The data points correspond to a geographic area 11 pixels west-east and 4 pixels north-south. For each image line, the decoder produces 11 sets of 23 interleaved fields of data.
Bands 20-23 of this data are not displayable; they hold the latitude and longitude of the first 19 bands. The latitude and longitudes are 32-bit values. Since the actual sounder data is 16 bits, the latitude and longitude values must be split in half to store them in the area structure.
Band 20 holds the two most significant bytes of the latitude; band 21 holds the two least significant bytes. Band 22 holds the two most significant bytes of the longitude; band 23 holds the two least significant bytes.
If the latitude and longitude values are not requested, the band list section will contain 20 bytes total with 19 bytes used.
These latitude and longitude values are in the Gould floating point format. See OGE, section 3.5.4. For example, if the latitude of a data point is 100.1640625, the hex representation is 42642A00; band 20 holds 4264, and band 21 holds 2A00.
This package does not provide any code for using these latitudes and longitudes; they are included only for reference purposes.
The four sounder detectors are numbered 1, 2, 3, and 4. Each data block line contains information from only one detector. The documentation block contains a field indicating which detector was used for the current line.
The line prefix contains a 4-byte validity code and a documentation region, which is described in the table below. The remainder of the line consists of the interleaved sounder data.
|
Documentation region |
Bytes |
OGE table |
|---|---|---|
|
If the value in word 49 of the area directory is 216, the first 180 words of the Sounder Auxiliary Data block have been inserted here. |
Navigation blocks contain 640 words. Unless otherwise noted, words are twos complement binary integers. Navigation information comes from Block 11 records, type 32. Bytes designated R*4 in the OGE Tables are in Gould format in the holding areas. They must be scaled and then converted to integer, or converted to Real on the machine doing the decoding, scaled as designated below, and then converted to integer.
If the latitude and longitude values are not requested, the band list section will contain 20 bytes total with 19 bytes used.
Because the word allocation information for the sounder navigation block is nearly identical to that for the imager, it is not repeated here. Only the words with a different description are shown below. That difference is usually the OGE table number and/or byte numbers.
|
Word |
Value |
Description |
|---|---|---|
|
scan status; bits 0-15 are right justified, bit 15 is the least significant bit; the IMC active flag is bit 8, counting from the least significant bit; 1=active (OGE Table 3-11, bytes 31-32) |
||
|
yaw-flip flag; bits 0-15 are right justified, bit 15 is the least significant bit; the yaw-flip processing enabled flag is bit 16, counting from the least significant bit; 1=enabled (OGE Table 3-10, bytes 57-58) |
||
|
repeat of Words 63-117 for pitch attitude angle (OGE Table
|
||
|
repeat of Words 63-117 for yaw attitude angle (OGE Table
|
||
|
repeat of Words 63-117 for roll misalignment angle (OGE Table 3-11, bytes 1211-1430) |
||
|
repeat of Words 63-117 for pitch misalignment angle (OGE Table 3-11, bytes 1431-1650) |
||
|
instrument nadir, north/south cycles (OGE Table 3-6, byte 3005) |
||
|
instrument nadir, east/west cycles (OGE Table 3-6, byte 3006) |
||
|
instrument nadir, north/south increments (OGE Table 3-6, bytes 3007-3008) |
||
|
instrument nadir, east/west increments (OGE Table 3-6, bytes 3009-3010) |
|
Word |
Value |
Description |
|---|---|---|
|
visible bias coefficients; one per detector (OGE Table 3-11, bytes 3075-3090) |
||
|
visible first order gain coefficients; one per detector (OGE Table 3-11, bytes 3091-3106) |
||
|
visible second order gain coefficients; one per detector (OGE Table 3-11, bytes 3107-3122) |
||
|
visible radiance to albedo conversion factor (OGE Table 3-11, bytes 3123-3126) |
||
|
IR bias scaling factors; one per IR channel (OGE Table 3-11, bytes 3991-4278); all channels contain the same values for each detector |
||
|
IR gain scaling factors; one per IR channel (OGE Table 3-11, bytes 4279-4566); all channels contain the same values for each detector |
||
The image source type VISR is historic in origin, going back to the early GOES satellites. At that time, data was 1-byte for both the visible and IR. Later satellites, such as GOES-6 and -7, were equipped with IR sensors that returned 10-bit values stored as two bytes. For data storage and transfer reasons, commands such as IMGCOPY can convert the 2-byte data to 1-byte. This conversion to 1-byte data preserves the temperature information for the IR channels. It is valid for GVAR, POES, Meteosat and GMS satellite data.
The image source type VISR is from word 52 of the directory block. If the area contains IR data, the temperature may be calculated from the pixel value using the formulas below, where T is the brightness temperature (degrees K) and B is the pixel value (0 to 255). For IR data, the highest pixel values correspond to the coldest temperatures.
The line prefix in a VISR area may be absent or it may contain only the 4-byte validity code.
|
The band information for GOES VISSR is provided in Appendix B, Image Information. |
GOES-7 produced data in two different modes:
Most GOES-7 data after 24 March 1987 (Julian day 87083) is AAA. This section documents the mode AAA for the IR and VAS instruments. Word 52 of the area directory contains the source type AAA.
The VAS senses the atmosphere for a given spatial location in up to 12 different IR spectral bands and one visible band. All or some of the IR bands may be included in a single VAS type area. The visible, however, may be contained in a separate area of VISR type. As a result, it may require two areas to contain the total information transmitted by the satellite during a given time period.
|
Word |
Value |
Description |
|---|---|---|
|
band filter map; a bit is set to one for each band appearing in the area |
||
The line prefix consists of a 4-byte validity code, 512 bytes of IR common documentation, and 116 bytes of VAS calibration information organized as follows.
|
Bytes |
Description |
|---|---|
|
13 eight-byte groups (1 per possible band) each containing:
|
The line prefix also contains 4, 8, 12 or 16 bytes of band list information; one byte for each band plus up to three bytes to round to the nearest whole word.
The structure of a VAS area is complicated by two facts:
What does appear on a given line is indicated in the band list section, which acts as an index for the line. Only the leftmost n bytes of the band list contain nonzero data, with n being the actual number of bands contained in each element of the line. The I th byte of the band list corresponds to the I th 16-bit pixel in each element of the line. Unused band list bytes are filled with binary zeros; the data in the unused pixel locations may not be zero, but in any case should be ignored.
The channel numbers range from 1 to 38; channel 39 exists but has never been put into service. Each is described in the table below.
|
Channel |
Detector |
Size |
Location |
Spectral band |
|---|---|---|---|---|
For a given spectral band, only one detector size is used in an area. However, two channels representing different positions of the detector for a particular band may appear in a single area although they may not appear on the same line. For example, channels 8 and 20 may appear in the same area, but not channels 8 and 36.
Unless otherwise noted, the words in the GOES-7 navigation block are twos-complement binary integers.
|
Word |
Value |
Description |
|---|---|---|
|
orbit parameters
|
||
|
attitude parameters
|
||
|
spin period (SPINP); the satellite period, in microseconds, or the spin rate in revolutions/minute |
||
|
frame geometry
|
||
|
camera geometry
|
||
|
betas for this area
|
||
|
gammas for this area
|
The calibration block is composed of the following data.
|
Word |
Value |
Description |
|---|---|---|
Transforming the VAS raw IR values into brightness temperatures is accomplished via the intermediate computation of calibrated VAS radiances. The array IAB contains two coefficients for each of the 38 channels; IFAB contains one scale factor for each channel.
If the channel is ICHAN, compute the radiance for the raw value P using:
The raw value P is divided by 32 because the data is stored as 15-bit numbers, but the coefficients expect 10-bit numbers.
The AVHRR (Advanced Very High Resolution Radiometer) instrument is a 5-channel scanning radiometer. It generates data in HRPT, LAC and GAC modes.
|
The band information for the AVHRR sensor is provided in Appendix B, Image Information. |
|
Word |
Value |
Description |
|---|---|---|
|
band map for the image, which has valid bits 1 through 6 for the new AVHRR/3 instruments on NOAA-15 (Note that if bit 3 is turned on, bit 6 must be turned on as well, and vice-versa, since both sensors share a single data band identified as either 3 or 6); determining which line belongs to which sensor can be made only from reading the line prefixes, except when an entire area contains only band 3 or only band 6 |
||
|
orbit position (ascending node, decending node, equatorial pass) |
The AVHRR navigation block is divided into 128 words.
|
Word |
Value |
Description |
|---|---|---|
|
sensor source, year and Julian day of the navigation, ssyyddd |
||
|
satellite is in a descending pass
|
||
|
time at the start of the first line, milliseconds from start-of-day |
||
|
time interval between lines, in microseconds (preferred over word 49) |
||
The calibration block is not used. Instead, calibration is done dynamically on a line-by-line basis to accommodate changing orbital conditions in the AVHRR/3 instrument. Therefore, the calibration data is contained in the data line prefixes. Refer to theTIRO and AVHR line prefix descriptions below, and Appendix D, POES AVHRR Calibration Information for additional information.
Because NOAA-12 and -14 AVHRR use the older TIRO calibration while the NOAA-15 AVHRR uses the newer AVHR calibration, changes have been made in the McIDAS-X area structure between the NOAA-14 areas and the NOAA-15 areas.
The AVHRR data block consists of data lines, each consisting of a line prefix and line data. The TIRO and AVHR line prefixes are different.
The TIRO line prefix for the data block contains the information below.
|
Region |
Description |
|---|---|
|
8 bytes; values 1 through 5 (left to right), with three pad zeros in successive bytes, indicate the order the bands will appear in each pixel in the subsequent data section |
The TIRO line prefix is defined as follows:
|
Byte
|
Section |
Description |
|---|---|---|
|
Words 7-102 of HRPT minor frame (all left shifted 5 bits into a 2-byte sample) |
||
|
Band 1 Slope/Gain 1 (all slopes and intercepts in the CAL block are scaled by 1000) |
||
|
Band 3 Space scan five sample average (rounded and left shifted 5 bits) |
||
|
Band 4 Space scan five sample average (rounded and left shifted 5 bits) |
||
|
Band 5 Space scan five sample average (rounded and left shifted 5 bits) |
||
The AVHR line prefix for the data block contains the information below.
|
Region |
Description |
|---|---|
|
8 bytes; values 1 through 5 (left to right), with three pad zeros in successive bytes, indicate the order the bands will appear in each pixel in the subsequent data section |
The AVHR line prefix for the data block is defined as folllows.
|
|
Byte
|
Size
|
|
|---|---|---|---|
|
Words 7-102 of HRPT minor frame (all left shifted 5 bits into a 2-byte sample) |
|||
|
Band 1 Slope/Gain 1 (all slopes and intercepts in the CAL section are scaled by 100,000 except for the band 3 slope) |
|||
|
Band 3 Space scan five sample average (rounded and left shifted 5 bits) |
|||
|
Band 3 Target scan five sample average (rounded and left shifted 5 bits) |
|||
|
Band 4 Space scan five sample average (rounded and left shifted 5 bits) |
|||
|
Band 4 Target scan five sample average (rounded and left shifted 5 bits) |
|||
|
Band 5 Space scan five sample average (rounded and left shifted 5 bits) |
|||
|
Band 5 Target scan five sample average (rounded and left shifted 5 bits) |
|||
|
For a complete description of the AVHRR instruments on the satellites and their calibration, see the NOAA-KLM User's Guide at http://www2.ncdc.noaa.gov/docs/klm or http://www2.ncdc.noaa.gov/docs/intro.htm. For instruments prior to 1988, see NOAA Technical Memorandum NESS 107, 1988 (now obsolete) or http://noaasis.noaa.gov/NOAASIS/ml/calibration.html. |
AVHRR data is transmitted as 10 bits and stored as 16 bits. The 10-bit data is formatted as follows, with x representing a data bit and the rest being zero-filled after shifting.
The 16-bit values from each of the five channels covering the same geographic area are stored interleaved in one image. The lines of data are stored in a time-ordered sequence and as the satellite scans right to left.
