4.0 LAS File Structures

4.1 Introduction

LAS creates a whole set of computer files related to the processing of its various components. The types and maintenance of some of the more common files used are described in this section. The types of files that may be found within LAS are:

The formats for each of these files and a complete list of the types of files found in LAS are described in detail in the LAS 7.0 Programmer's Guide.

4.2 LAS Filename Syntax

The traditional LAS filename syntax is based on VMS filename conventions, with additional fields for handling image subwindows, band sets, etc. (described in later sections). Support for the native Unix directory/filename syntax is the new LAS standard, with backwards compatibility to support the previous standard, VMS-style directory/filename syntax.

Following are the requirements for a filename in LAS:

1.
  The traditional LAS format, based on VMS conventions (square brackets, directory levels separated by dots, semicolons separating root name and extension), will continue to be supported. This includes directory options to define the entire path, start at the user's home directory, start at the local directory, and start at the parent of the local directory (i.e., ``[-]'').
(a)
  If a directory/filename contains square brackets (``[]'') and/or a semicolon (``;''), it will be interpreted with VMS syntax.
(b)
  The input directory/filename will be interpreted as case-sensitive. This is a departure from the existing case-insensitive standard of converting to all lower case during conversion to a host name.
(c)
  An extension may be added to the filename depending on the form of the input filename.
i.
  If a filename has been determined to be in VMS syntax and contains a semicolon, the filename as input is assumed to be complete and no extension will be appended.
ii.
  If a filename has been determined to be in VMS syntax and does not contain a semicolon, a default extension (application based) may be appended.
2.
  Unix directory/filename syntax (forward slashes separating directory levels, dots separating root name and extension, case-sensitive) will be supported as the new LAS filename syntax standard.
(a)
  If a directory/filename does not contain square brackets and/or a semicolon, it will be interpreted with Unix syntax. VMS format will only be assumed if VMS-specific characters exist. (See requirement 1a.)
(b)
  In Unix syntax, dots are not restricted to representing only file extensions the way that semicolons are in traditional LAS format. This can lead to ambiguities in some applications.
i.
  If a specific extension is required and the Unix filename ends with the required extension, the filename as input is assumed to be complete and no extension will be appended. Required extensions only apply to image file sets (``.img'', ``.ddr'', ``.his'').
ii.
  If a specific extension is required and the Unix filename does not end with the required extension, the required extension will be appended to the filename.
iii.
  If a LAS input filename parameter does not require a specific filename extension, the filename will be determined as follows:
a.
  If the filename contains at least one dot, the string following the last dot is interpreted as the extension and the input name is used.
b.
  If the filename does not contain any dots, the default extension is appended to the name. (No default or an empty default are interpreted as a default extension of nil and will append nothing.)
3.
  The legacy capabilities to specify windows, bands, and multiple images in a single input string shall continue to be supported. The details are given in later sections.
4.
  Input strings that do not match either the VMS format or the Unix format will induce an error.
(a)
  If a directory/filename contains illegal characters an error will occur. Legal characters (not including those associated with windowing/banding information) in VMS format are all alphanumerics, ``[].;-@_#%^'' , and `*'' (as a wildcard in certain applications). Legal characters in Unix format are all alphanumerics, ``~/.-@_#%^'' (``~'' only as the first character in the path), and ``*'' (as a wildcard in certain applications). The plus sign (``+'') is a legal character in both VMS and Unix syntax, but should be avoided due to potential confusion with its line continuation role in the LAS command line.
(b)
  If a directory/filename contains multiple left or right square brackets, multiple semicolons, or multiple tildes, an error will occur.
If the user-specified name for an image or file in a LAS applications module is input in traditional, VMS syntax, it's translated into a host computer name. During this translation all periods "." are turned into underscores "_" and a period and file extension are added to the name. For example:


     IN = [-]madtown.tm

will be stored, along with DDR and history files, in the files called:

madtown_tm.img (image file)
madtown_tm.ddr (DDR file)
madtown_tm.his (history file)

in the parent directory of the current working directory.

To store another user-created file with this image, such as a text file, would require the user to follow a similar naming convention such as:


     madtown_tm.txt (a text file created by the editor).

4.3 LAS Catalog Manager

All LAS files created during the sessions are cataloged and maintained by the LAS Catalog Manager (CM). The CM modules used to manipulate and integrate the catalog are:

Module Description
cmalias Creates,deletes, and lists aliases
cmcopy Copies cataloged on-line and off-line files
cmdel Deletes directories or cataloged files
cmlist List cataloged files
cmmkdir Creates a new directory
cmrename Renames a cataloged file
cmset Sets the user's default directory
cmshow Shows the current catalog directory

Wildcards are allowed for the filename, extension, and the last directory specification of most catalog manager applications. A more general directory wild card is allowed for those applications which include the parameter nlevels, the number of child or subdirectories to search. In such an instance, a wildcard can be substituted for the entire filename specification. The following list provides guidelines about wildcards in catalog manager filenames.

Examples:

Images under the user quirk:


     dogimagesnoopy

     landsat_image_band1

     landsat_image_band2

     landsat_image_band3

     madtown

     spot_isoclass

*image*

Would find:


     dogimagesnoopy.img

     landsat_image_band1.img

     landsat_image_band2.img

     landsat_image_band3.img

*t_

Would find:

None of the previously listed examples.

*t_*

Would find:


     landsat_image_band1.img

     landsat_image_band2.img

     landsat_image_band3.img

     spot_isoclass.img

*1*

Would find:


     landsat_image_band1.img

~quirk/*.*

Would find:


     dogimagesnoopy

     landsat_image_band1

     landsat_image_band2

     landsat_image_band3

     madtown

     spot_isoclass

4.4 LAS Data Structures

4.4.1 Image Storage

LAS images will always have the following information associated with them:
Each image may also have another set of associated files, which may include any of the files listed in Section 4.

In the course of processing raster images, several types of associated data files may be created for each image. LAS uses a standard set of extensions to implicitly associate a file with an image. All files in a directory with the same filename but different extensions are considered to be associated. The existence of separate files for the associated information gives increased flexibility, simplifies the task of accessing the associated information, and allows the image and its associated files to be easily treated as a "data set" for archive and file transfer. Files may use any extension; however, some standard extensions are used in naming types of files that are frequently used and the user should avoid using these extensions. Some of the file types are:

Extension Description
dltf Display and lookup table file
ddr Data descriptor record (DDR)
gof_pnt Graphics overlay point file
gof_line Graphics overlay line file
gof_poly Graphics overlay polygon file
gof_anot Graphics overlay annotation file
grid Geometric mapping grid
his History
ibis_tab LAMS tabular file
ibis_graph LAMS graphics file
lt General purpose labeled table file
img Image data file
mtp Merged tie point file
rwt Resampling weight table file
proj Projection definition file
stat Statistics file
tpl Tie point location file
tps Tie point selection file
txt General purpose ASCII file

LAS stores the image data and associated data in separate files. Multiband images are stored in the same file in a band sequential (BSQ) format. Image data may be transferred or ingested from computer compatible tapes to disk, or from disk to disk. Image data may also be transferred as output to tape from disk.

4.4.2 Multi-band Images, Spatial, and Spectral Specifications

LAS applications modules accept both single-band and multi-band images. An optional spatial window specification may be used along with the image name, such as:


     "LASIMAGE(SPATIAL_WINDOW : SPECTRAL_WINDOW; SPATIAL_WINDOW_TYPE)"

Restrictions and notes:
  1. The image name can be 100 characters long. The LAS image name represents the name as one of the following:

  2. The window specification is given as SL, SS, NL, NS where:

The individual window specification values must be delimited by either a blank space or a comma. The following examples are valid ways of using or combining image names:


     "lasname1(200,200,100,100:2,3,4,5)+lasname2(1,1,100,100:3,5)"

The images lasname1 and lasname2 are considered as multi-band images in this example. The window 200, 200, 100, 100 will be applied to all the bands of the selected bands 2, 3, 4, and 5 from lasname1 and bands 3 and 5 using the window 1, 1, 100, 100 from lasname2. Note that the spectral window size must be the same in most LAS modules. The exception is concat.

The following rules and limitations apply:

To create an image of multiple files or bands, the user may use the LAS module copy. For modules with single logical images--such as copy, normd, and list, IN will be a single-dimensioned parameter with the following allowable images:


     IN="image1"

     IN="image1(1 1 100 100)"

     IN="image1(:1 2)"

     IN="image1(1 1 100 100:1 2)"

     IN="image1+image2"

     IN="image1(1 1 100 100)+image2(1 1 100 100)"

     IN="image1(:1 2)+image2(:1 2)"

     IN="image1(1 1 100 100:1 2)+image2(1 1 100 100)"

As an example, this is how a LAS module will handle singledimensioned IN parameters and what the results will be.

     COPY IN="image1(:1 2)+image2(:2 3)" OUT="image3"

In this example, bands one and two of image1 are copied as bands one and two of image3 along with bands two and three of image2 which are bands three and four of image3. This example shows how a user can group four bands of two images into four bands of one image.

For modules that allow or expect multiple logical images - such as math, composit, and diff - IN will be a multidimensioned parameter with the following allowable images:


     IN="image1, image2"

     IN="image1(1 1 100 100), image2(1 1 100 100)"

     IN="image1(:1 2), image2(:1 2)

     IN="image1(1 1 100 100:1 2), image2(1 1 100 100:1 2)"

     IN="image1+image2, image3+image4"

     IN="image1(1 1 100 100)+image2(1 1 100 100),
         image3(1 1 100 100)+image4(1 1 100 100)"

     IN="image1(:1 2)+image2(:1 2), image3(:1 2)+image4(:1 2)"

     IN="image1(1 1 100 100:1 2)+image2(1 1 100 100:1 2), 
         image3(1 1 100 100:1 2)+image4(1 1 100 100:1 2)"

In addition, the comma may be replaced with a blank, and the elements may be entered individually as in the following examples:

     IN(1)="image1"

     IN(2)="image2"

     IN="image1(:1 2) image2(:1 2)"

     IN(1)="image1(1 1 100 100:1 2)+image2(1 1 100 100:1 2)"

     IN(2)="image3(1 1 100 100:1 2)+image4(1 1 100 100:1 2)"

As an example, this is how a LAS module will handle multidimensioned IN parameters and what the results will be.

     MATH-ADD IN="image1(:1 2),image2(:2 3)" OUT="image3"

In this example, bands one and two of image1 are added, respectively, to bands two and three of image2. The output image3 consists of two bands. The first band is the sum of image1 band one and image2 band two with the second band consisting of the sum of image1 band two and image2 band three. This example shows how the user can treat the input images as two separate unique images as opposed to the first example where the input is treated as one logical input image.

4.4.2.1 Optional Specifications

Optional spatial window specifications include:


     "LASIMAGE(SPATIAL_WINDOW : SPECTRAL_WINDOW; SPATIAL_WINDOW_TYPE)"

This format may be used in place of the standard image specifications discussed in Section 4.4.2.

The SPATIAL_WINDOW has three possible definitions.

  1. default:

    (SL SS NL NS)

  2. method 2:

    (MAX_LAT MIN_LON MIN_LAT MAX_LON)

  3. method 3:

    (UL_Y UL_X LR_Y LR_X)

The SPATIAL_WINDOW_TYPE defines the format of the window components and may be set to:

Key Units Definition
Not specified Line/Sample default
"LS" Line/Sample default
"DEG" Degrees method 2
"DMS" DDDMMMSSS.SSSS method 2
"PRO" Projection method 3

If SPATIAL_WINDOW_TYPE corresponds to the default method, then the window will be processed the same as the standard method described in Section 4.4.2.

If SPATIAL_WINDOW_TYPE corresponds to method 2, then:

  1. The specified latitudes and longitudes are assumed to be in the GEOGRAPHIC projection.

  2. The input IMAGE DDR must contain valid projection information and corner values.

  3. The window is transformed to the image projection using the projection information in the IMAGE DDR and the General Cartographic Transformation Package.

  4. Some examples would be:
 
          IN="image1(20.3 120.5 18.6 118.2:1 2;DEG)"

          IN="image1(020018000 120030000 018048000 118012000:1 2;DMS)"

          IN="image1(20.3 120.5 18.6 118.2:1 2;DEG),
              image1(020018000 120030000 018048000 118012000:1 2;DMS)"
If SPATIAL_WINDOW_TYPE corresponds to method 3, then:
  1. The specified coordinates are assumed to be in the same projection as the IMAGE DDR.

  2. The input IMAGE DDR must have a valid pixel size.

  3. The line sample window is calculated directly from the input window using the formulas in the Geometric Overview.

  4. Some examples would be:
          IN="image1(103400 234560 98650 239640:2 3;PRO)"

          IN="image1(207300 125430 187520 145360;PRO"

4.4.3 Associated Files

4.4.3.1 Image History

Image history information is stored in an associated history file. The image history consists of the modules used in the creation of the image, modules run using the image, data and time executed, and parameters used.

The history of a LAS image file may be displayed on the terminal by running the module dsphistry or by using any computer system utility which will display an ASCII file.


     Fri Sep  1 16:55:23 1989
     UNIX
     quirk
     GEOM1P
     IN="nhap_raw_map"
     INGRID="nhap.grid"
     OUT="nhap_reg"
     WINDOPT="OUT"
     WINDOW=--
     RESAMP="CC"
     INRWT=--
     PCCALPHA=-0.5
     BACKGRND=0.0
     INTLIM=--
     ODTYPE="SAME"

     Tue Sep  5 08:37:23  1989
     UNIX
     quirk
     copy
     IN="nhap_reg(2232,2943,2100,2709)"
     OUT="nhap_reg_sub"
     ODTYPE="SAME"
     ROUNDOPT="TRUNC"

     Thu Sep 7 00:36:01 1989
     UNIX
     quirk
     ISOCLASS
     IN="nhap_reg_sub"
     OUT="nhap_reg_iso"
     OUTSTAT="nhap_stats"
     STATSRC="NONE"
     INSTAT=--
     MAXNUMIT=10
     CLUSDIST=3.2
     MAXCLSTD=4.5
     SSEPVAL=0.0
     PRINTIT=11
     VIEWIT=21
     MINNUM=30
     MAXCLUST=24
     CHNTHR=3.2
     PRINT="LP"
     PRTFILE="ISOCLASS_112544.pr"

4.4.3.2 Data Descriptor Record

Every image will have an associated data descriptor record (DDR) file. This file contains the contents shown below.

The DDR file contains five basic types of information. Each time a module is executed, each of the fields is updated. The rules governing how each field is updated is outlined in the LAS 7.0 Programmer's Guide. The DDR can be displayed using the LAS module dspddr, or each of the fields can be edited by using the LAS module editddr. The five types of information in the DDR are:

  1. Required information about the image - number of lines, number of samples, number of bands, data type, and the system on which the data was created

    Most modules only require that the number of lines, number of samples, number of bands, data type, and the system the data was created on be valid for the module to use this DDR; all the other fields may be invalid. There are some modules which require other fields to be valid. For example, concat-auto requires that the corner coordinates and related projection information to be valid.

  2. Corner coordinates of the image and the related projection information

    These coordinates are useful in the mosaicking of images and/or retrieval of the projection coordinates of any pixel in the image. For a more detailed description of these fields and how they can be used, refer to the Geometric Manipulation Package Overview document.

  3. The minimum and maximum values for each band of the image

    This is calculated by any module that creates an output image and only when the TAE global $MINMAX is set to "yes."

  4. Information describing how and when each band of the image was acquired

    These fields are used to keep track of acquisition date and time of each band of the image and how it was acquired.

  5. Miscellaneous information

    This information includes the last date and time an image was modified and the master line and sample of an image. The last access date and time are useful in deciding which images should be archived. The master line and sample keep track of where pixel 1,1 of the image is in relation to the original image. This is useful if the image has been copied or used as a subset.


     IMAGE NAME:image/valddr
               NL:512           NS:512            NB:3          DTYPE:BYTE
     LAST USED:            DATE:26Jan89     TIME:1451:03   SYSTEM:gouldutx
     PROJ. CODE:(1)UTM                                         Valid:VALID
     ZONE CODE:11                                              Valid:VALID
     DATUM CODE:0                                              Valid:VALID
     PROJ. PARM:                                               Valid:VALID
     A:   0.00000000000000E+00   0.00000000000000E+00   0.00000000000000E+00
     B:   0.00000000000000E+00   0.00000000000000E+00   0.00000000000000E+00
     C:   0.00000000000000E+00   0.00000000000000E+00   0.00000000000000E+00
     D:   0.00000000000000E+00   0.00000000000000E+00   0.00000000000000E+00
     E:   0.00000000000000E+00   0.00000000000000E+00   0.00000000000000E+00
     CORNER CORR:                                              Valid:VALID
        ULcorner:3.65777500000000E+06   4.99200000000000E+05
        URcorner:3.65777500000000E+06   5.11975000000000E+05
        LLcorner:3.64500000000000E+06   4.99200000000000E+05
        LRcorner:3.64500000000000E+06   5.11975000000000E+05
     PROJ. DIST:2.50000000000000E+01   2.50000000000000E+01    Valid:VALID
     PROJ. UNITS:meters                                        Valid:VALID
     INCREMENT:0.00000000000000E+00   0.00000000000000E+00     Valid:INVALID
     MASTER CORR:0       0

     IMAGE NAME:[image]valddr
     BAND NO:1
     MINIMUM:0.00000000000000E+00                              Valid:VALID
     MAXIMUM:1.95000000000000E+02                              Valid:VALID
     DATA SOURCE:landsat4
     SENSOR TYPE:mss
     CAPT. DIRECTION:ascending
     DATE:23apr86
     TIME:1305:55

     IMAGE NAME:image/valddr
     BAND NO:2
     MINIMUM:0.00000000000000E+00                              Valid:VALID
     MAXIMUM:2.33000000000000E+02                              Valid:VALID
     DATA SOURCE:landsat4
     SENSOR TYPE:mss                          
     CAPT. DIRECTION:ascending
     DATE:23apr86
     TIME:1305:55

     IMAGE NAME:image/valddr
     BAND NO:3
     MINIMUM:0.00000000000000E+00                              Valid:VALID
     MAXIMUM:1.64000000000000E+02                              Valid:VALID
     DATA SOURCE:landsat4    SENSOR TYPE:mss
     CAPT. DIRECTION:ascending
     DATE:23apr86
     TIME:1305:55

4.5 Statistics Files

In the process of interpretation and image analysis, some LAS modules use or generate statistics files. These files may or may not be associated with a specific LAS image. LAS statistics files are tree-structured files that contain statistical information derived from the associated images. The types of information contained in statistics files are mean and covariances matrices, correlation data, histograms, and polygon vertices.

When training sites are defined by the mensuration modules, the site polygon vertices are based on entire image coordinates even if the image needed to be subsampled to be displayed. For example, if polygons are selected from a 512 by 512 subsection, starting at image coordinates (1001,2001) , the coordinates of any site polygon within that subsection will be in the range (1001,2001) to (1512,2512). This is important to users who wish to edit their polygon vertices.

4.5.1 Nodal Structure

The data in a statistics file is stored in a data tree structure. The tree structure consists of three levels. The three levels are:

Level 0 contains only one node which is the root of the data tree. The nodes that belong to the Level 1 category are immediate successors of the root node. The nodes that belong to the Level 2 category are immediate successors of the nodes in Level 1.

Statistics files are generated by the clustering/classification modules such as isoclass or by the training site definition module put-poly. Note that the statistics files generated by the clustering/classification modules may not have any "sites" for Level 2; they may only have class information at Level 1.

4.6 Display and Lookup Tables

Display and lookup tables files (DLTF) are used within LAS to store lookup tables that are utilized by both the LAS display module (XID) and enhancement modules such as map. A DLTF is a file that defines a sample intensity mapping to be applied to an image. The sample value in an input image is the index to the DLTF, and the contents of the index is the sample value of the output image that would result if the DLTF was applied to the input image. DLTF can be used on either black and white or color images.

4.7 Geometric Transformation Files

Several types of files are used in performing geometric transformation of image data in LAS. Not all geometric corrections will use all of the file types listed as described in the following list, although some of them will. Additional information may be referenced in the Geometric Manipulation Package Overview document. The types of files used in geometric registration are:

4.8 TAE Files

TAE also creates and updates a set of files on the computer system. These include parameter files, session histories, PDFs, script files, and the results of batch processing. These files are described in detail in the TAE User's Reference Manual, but several are included in the following list. These files may be found under any user's account by using the computer system's file listing utility.

File Descriptions:

pixcount.par
A parameter file that the user saved from the pixcount module. These parameter files may be saved from any LAS module with the default name being the module name. They are binary files.

last.par
The file where the parameters are saved for the last module the user ran. This allows the user to use the restore last capability in TAE.

session.tsl
This file contains all information from a particular session if enable-log has been set.

taescreen.txt
File created by typing screenon followed by screenoff. It stores all the tutor screens displayed between these two commands in this file. This ASCII file may be viewed and/or printed.

ulogon.pdf
A file setup by the user and executed when the user starts a LAS session. It allows a user to customize his/her LAS session.

ulogoff.pdf
A file setup by the user and executed when the user ends a LAS session. It allows a user to customize his/her LAS session.

procname.job
These files are created by running a module in batch mode.

procname.log
A log file of the batch job.

name.src
Script files saved using the scripton and scriptoff sequence of commands.

name.pdf
TAE proc that can be setup by the user to run interactively or in batch mode.