satellite or aircraft image data. Aircraft and satellite profiling sensor 
data was to be accomodated if possible, and finally it was hoped that 
geographic or cartographic data in polygon form could also be handled. The 
success of the designers of the Format was demonstrated by its wide 
acceptance by the remote sensing community. In addition, the major Canadian 
Federal Government operators of large Geographic Information Systems were 
able to adapt the format to the transfer of polygon data through the Spatial 
Data Transfer Format (Goodenough, et al., 1979). A variation of this format 
was later adopted by the Canadian Committee on Surveys and Mapping, which 
represents a wide variety of federal and provincial mapping agencies 
throughout Canada. 
This CCT Format Family can accommodate many extant formats without extensive 
reformatting by adding a superstructure to data recorded in existing 
formats. This superstructure identifies the format and provides a logical 
guide to reading the tape. It has two components: a Volume Directory which 
generally describes the data configuration and provides pointers to each of 
the data files; and a File Descriptor in each file which describes the data 
structure within the file. The Format Family does depend upon external, 
written documentation for the definition of the format, the structure of the 
various records and the definition of the logical formats of the data 
fields. 
SPACE DATA ACTIVITIES 
A new committee, the Committee on Earth Observation Satellites (CEOS), was 
formed in 1985 to standarize the formats and other factors of earth 
observation space data for the Space Station era. This committee is 
considering data from various earth-looking sensors. Initial consideration 
is being given to the LANDSAT CCT family as a foundation for such a common 
format. 
An international body, the Consultative Committee on Space Data Systems 
(CCSDS), is defining a nev, generic structure for use in the Space Station 
and its data systems. It is hoped by the Committee that this structure will 
also find general use. This structure is a nested Type-Length-Value set of 
frames called the Standard Formatted Data Unit (SFDU). 
The Type field is fixed format with pre-defined codes for various entries, 
the SFDU-length field is fixed length, and the value field is the variable 
length defined in the SFDU length field. The value field is the data field, 
and may contain any desired data, including more SFDUs. The structure at 
this definition level is generic. 
The SFDU is primarily designed to be operational in an environment in which 
utmost stress is placed on the ability of the receiving software to 
recognize a message and parse it in an absolute minimum of time in 
anticipation of further messages immediately to follow. A prime mode of 
operation, therefore, is quick message recognition and local lookup of 
message handling instructions. This precludes the parsing of format 
definition information in the message. 
However, to accommodate those situations in which self-contained data 
definition is desired, the SFDU may contain an internal SFDU module which 
contains the necessary structure definition. Being considered as the data 
definition language is the General Data Interchange Language  (GDIL) 
(Billingsley, 1985), described in some detail below. The GDIL is a generic 
ISO Level 6 description of the field structures of the various records plus 
the logical structure definitions of the data fields. 
186 
  
In 
Agr 
Spa 
for 
was 
dev 
The 
spe 
prc