IPAC Table Format

Version 1.2 5/23/13

Introduction

IPAC Table Format is a simple, easy-to-read format for ASCII tables and supplemental information dating from the 1990s. The format standard definition (current as of Apr 2013) is stated here. Implementations in some public software applications may vary. In general, we recommend that applications can accept variations on the standard described here, but should write within the standard. Some of the details where flexibility may be desirable on reading are noted below as being part of the "standard".

Note: There are currently some restrictions on an uploaded IPAC table within IPAC's Infrared Science Archive's catalog search ("Gator") and WISE Image Archive.

Table Organization

You can download and edit a sample table. All applications need to be able to read this table.

An IPAC table is organized as follows (red notes are not part of the table -- just for reference):


\keyword = value                                                  Keywords (optional)
\ Comment                                                         Comments (optional)
|  column1  |  column2  | column3 |  column4 |    column5       | Column Names (required)
|   double  |   double  |   int   |   real   |     char         | Data Types (standard)
|   unit    |   unit    |   unit  |   unit   |     unit         | Data Units (optional)
|   null    |   null    |   null  |   null   |     null         | Null Values (optional)
  165.466279  -34.704730      5      11.27         K6Ve           Data Rows (1 required)
 
Data should remain within columns with no data under the vertical bars (standard).

IPAC Tables are space-delimited in the standard. Header lines are marked by, and have columns defined by, vertical bars ("|"). Data are separated by spaces and lie within the columns marked by the bars and do not fall directly under a bar (standard). One can formally refer to IPAC Table Format as IPAC ASCII Column-Aligned Format.

The first header, Column Names, is required. If a 2nd header line is present, it must be the Data Types (present in the standard). If a 3rd header line is present, it must be the Data Units. It and a 4th header line, Null Values, are optional. At least 1 row of data is required. The number of data entries in a row should match the number of column names (standard) and no blank row is allowed.

Keywords and Comment Lines

Users may define their own keywords at the top of the file. These keywords follow the FITS keyword = value style. They must be preceded by a backslash ("\"), with no space between the "\" and the keyword. The keyword is followed by an equals sign ("="), followed by the value. Spaces around the "=" are allowed. The value may be bare, or quoted using single or double quotes.

A "\" followed by a space is treated as a comment line.

Examples of valid keywords and comments:

\catalog = sao
\date = "Wed Sp 20 09:48:36 1995"
\mykeyword = 'Another valid string value'
\ This is an example of a valid comment

Examples of invalid keywords and comments:

     catalog=sao                    No starting backslash 
     \This is not a valid comment   No space between backslash and comment

A special keyword is \fixlen = T. This indicates to the application reading the table that the table data are stored in records of fixed length. This makes searching easier for the application.

Column Headers

Column Names:

Column Names can be any printable characters, except a vertical bar ("|"). No duplicate column names (standard).

For compatibility with older applications, it is best to use lower case "ra" and "dec" for right ascension and declination. (See note below on Case Sensitivity.)

Data Types:

Allowed Data Types:

  • int
  • long
  • float
  • double
  • real - interpret as "float", unless all floating-points are "double"
  • char
  • date

For compatibility with older applications, it is best to use lower case. (See note below on Case Sensitivity.) Data Types may be abbreviated using the first letter, or more. However "d" cannot be used for "date" as it is interpreted as "double".

Data Units

Data Units can be any printable characters, except a vertical bar ("|"). If the data have no units, leave blank.

Null Values

The Null Values define the data values that will indicate no data, for example "null" or "9999.99". They can be any printable characters, except a vertical bar ("|"). The null value in the header must consist of precisely the same characters as the null value used in that column. For example, "-99.0" is different from "-99.000".

Do not use dashes as "spacer" counters in the headers ("---value---"). This is to allow an initial minus sign where needed. (In some older table readers, dashes were interpreted as spacers.)

Common Issues

Case Sensitivity - Whether words are upper or lowercase is not specified in the format, but by the application. For example, the application must have a rule about whether column names "ra" and "RA" will be mapped to the same variable, and what to do if both are present.

Limits - Limits on sizes of table strings, numbers of keywords or comments, numbers of data columns or rows, etc. are set by the application.

Brevity is Best - Keeping keywords, comments, headers, etc. brief is good practice, both for readability and in case an application truncates.

Example Tables