IPAC Table Format
Version 1.2 5/23/13
- Table Organization
- Keywords and Comment Lines
- Column Headers
- Common Issues
- Example Tables
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.
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.
Allowed Data Types:
- real - interpret as "float", unless all floating-points are "double"
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 ("|").
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.)
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.