Invoking "GeoTab"
         for cataloguing PDS databases


written by J. Kevin Jennings
kjennings at swri.org

Created: 01/13/2005
Updated: 06/05/2007

Table Of Contents

  1. Basic Invocation
  2. The Configuration File
  3. General Program Logic
  4. Historical/Annotational Points

Basic Invocation

GeoTab requires the user to input the name of a configuration file.
The definitions required by GeoTab are, at a minimum:

Sample invocations:

All defined parameters may be included in the configuration file.
Any parameters defined on the command line will override those defined in the configfile.
For instance, should the configfile (let the filename be "myconfig") contents be this:

          REF_TARGET_NAME EARTH
          DATA_DIR: DATA/DATA11
          PHASE_FILENAME: MEX_SCIENCE_SUBPHASE_DEFS.TAB

...then an invocation of:
          GeoTab -f myconfig
would run processing with EARTH as the target name,
while an invocation of:
          GeoTab -f myconfig -t MARS
would override the value in the configuration file and execute processing with a target name of MARS.

The Configuration File

The following sample file contents represent the flexibility allowed in creating a configuration file:
          REF_TARGET_NAME EARTH
          REVISION = 5
          RELEASE:3
          # am using the test data directory #11
          DATA_DIR: DATA/DATA11
          # The Phase File contains definitions of mission phases.
          PHASE_FILENAME: MEX_SCIENCE_SUBPHASE_DEFS.TAB
          LABEL:Testing Use of Config File
          DATA_SET_NAME Testing Latest Version
          GEO_KERNELS geo.kernels

Note that the lines beginning with a "#" symbol are treated as comments.
Note also that the user may separate PARAMETER:VALUE pairs in several ways:
          ":", "=", " "(space-delimiting).
The first non-whitespace field of a configuration line is taken to be the parameter to be configured and the rest of the line is accepted as the value to assign. Note, then, that no configuration identifiers contain whitespace, though their assignment values may.

General Program Logic

The objective of GeoTab is to produce a catalogue database file which conforms to standards defined in the ESA document SOP-RSSD-TN-010.
A "logical archive volume" is a set of CSV/LBL file pairs from a PDS-formatted database.
A "data product" is one pair of CSV/LBL files from within the logical archive volume.

The catalogue database is referred to as a geometry index file and consists of two files: a .LBL file and a .TAB file.
The geometry index file contains summary information to help the user locate the correct data product from within the logical archive volume. Using the .LBL and .TAB files together provides the user with a working index of the logical archive volume which may be loaded directly into a spreadsheet. This requires that the .TAB file be written to a fixed format throughout and that each column in the .TAB file be defined by an entry given in the .LBL file.

Given a list of CSV files [the contents of a logical archive volume], GeoTab creates one geometry index file pair (.TAB/.LBL). For each data product within the logical volume, a set of entries is created in the geometry index file. Each data product has start/stop times associated with it and there should be entries in the index file for at least these times; in addition to start/stop time entries, the index file should contain entries for timesteps within the file at a nominal spacing of 10 minutes [a file whose contents spanned 55 minutes, then could have 7 entries].

Each time GeoTab is invoked, a new .LBL/.TAB file is created. However, should there be a pre-existing pair of index files their contents are absorbed into the contents for the new files. Entries in the new set of data files which are already accounted for in the existing index files are not duplicated. Should the new set of data files require that the lines in the .TAB file be extended, then all pre-existing .TAB entries are re-written to the proper format.

During the cataloguing [and for any merging of previous contents] of a dataset, certain parameters are required to be in constant agreement among the data files. These parameters are:
          PDS_VERSION_ID
          DATA_SET_ID
          INSTRUMENT_HOST_NAME
          INSTRUMENT_NAME

Historical/Annotational Points

The program used to require agreement between data files for the following parameters, but changes to the index files nullified the need for requiring these to agree:
          TARGET_NAME
          TARGET_TYPE

Dec. 2004 - per request of ESTEC, the following values are to always be used for TARGET_TYPE and TARGET_NAME when writing the LBL file:
      REFERENCE_TARGET_NAME         EARTH          MARS
                 TARGET_NAME       SOLAR WIND       MARS
                 TARGET_TYPE      PLASMA CLOUD     PLANET

Changes in calls to the Spice library may necessitate changes to calls in GeoTab. For instance, an updated version of Geolib [v 1.0] required the user to specify which spacecraft was to be used as a reference point for the data returned; as a result, an extra variable, "SpacecraftName" was added as a global variable to be used for these calls.

Because the code must accommodate the merging of existing .TAB files, there is a need to verify that output lines are, in fact, unique. If the user is confident that existing .TAB files will not contain duplicate data to the files currently being processed, then execution will be much faster if the checking for duplicates is turned off. To turn off checking for duplicates, invoke the program with -Q on the command line. Alternatively, if the program is run with duplicate checking turned on and the user decides to turn checking off during program execution, then Ctrl+C will allow the user the opportunity to do so.