Home About Holdings Missions Documentation Help Desk
 

IPAC Table Format

 

 

It is strongly recommended that users use ASCII character encoding in IPAC Tables. Properly aligning the columns may be very difficult using multi-byte character encodings.

File Names:

The file name for an IPAC format table can up to 80 characters long which is case sensitive. File name can contain special characters, but no spaces, carets ("^"), or ampersands ("&") are allowed. Any tables which may be loaded into database have to follow DBMS constraints.

Examples of valid IPAC table names:

Examples of invalid IPAC table names:

Table Organization:

The body of the table is organized as follows (red and green lettering are not part of the table, but are used to assist in explaining each line of the table):


\name=value                                                       Keyword lines
\ Comment                                                         Comment lines
|  column1 |  column2 | column3 | column4  |    column5       |   Column Names
|  double  |  double  |   int   |   double |     char         |   Data Types
|   unit   |   unit   |   unit  |    unit  |     unit         |   Units (optional)
|   null   |   null   |   null  |    null  |     null         |   Null Values (optional)
 2.0978     29.09056   73765     2.06000    B8IVpMnHg             Data Records


 1111111111 2222222222 333333333 4444444444 555555555555555555    

This sample row shows no data is allowed under the vertical bar
in the header.

If a header contains three lines, the third line is considered to be units line. Users are advised to either use both optional header lines (units and nulls), or to use neither of them and have just the two required header lines.


Keyword and Comment Lines:

The user may define their own keywords at the top of each table file. These keywords follow the FITS keyword=value model, and are case sensitive. They must begin with the backslash ("\") character, with no spaces between the backslash and the keyword itself. The keyword is followed by an equals sign ("="), followed by the value. The IPAC table format allows spaces around ("=") signs. Header keyword string values should be quoted using single or double quotes.

 

A "\" followed by a space is treated as a comment line. Comment lines should have no more than 80 characters.

Examples of valid keywords and comments:

\catalog = sao
\date = "Wed Sp 20 09:48:36 1995"
\mykeyword = 'Another way for defining keyvalue string'
\ This is an example of a valid comment
\
|     ra   |    dec   |   sai   |      v   |    sptype        |
|    real  |   real   |   int   |    real  |     char         |
 

Examples of invalid keywords and comments:

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

Column Headers:

There are up to four possible header lines for each column in the table, in the following order:

Each header line must use the vertical bar ("|") character to mark the column boundaries. For example:


  |     ra   |    dec   |   sao   |      v   |    sptype        |
  |  double  | double   |   int   |    double|     char         |
  |    unit  |   unit   |   unit  |    unit  |     unit         |
  |    null  |   null   |   null  |    null  |     null         |
    2.09708   29.09056     73765    2.06000   B8IVpMnHg

Dashes can be used in place of the spaces in the header:

|-----ra---|----dec---|---sao---|------v---|----sptype--------|
    2.09708   29.09056     73765    2.06000   B8IVpMnHg
Bars ("|") at the start and end of each line are required. The use of tabs to fill spaces in the header lines is strictly forbidden.

Column Names:

The column names of an IPAC table may be up to 40 characters, which are case sensitive. The column names can be the combination of characters, numbers, or underscores ("_"). The blanks, white spaces, tabs, dashes ("-"), or any other spacial characters are not allowed as part of column names . For example, use "U_mag" instead of "U mag".

In addition, when a data provider supplies IRSA with a table which needs to be loaded into a database (DBMS), there are more constraints to the allowed column names. Please read more detailed information regarding DBMS column constraints.

Possible Data Types:

IPAC table format accepts those datatypes:

In rare cases where the table is compact and where there is no enough space for a complete datatype name, a single character name equivalent can also be used as the datatype:

Null Values:

The null value in the header defines actual null values for each column. IRSA's table library can interpret the data records and store the data, together with null information, in the database if needed. For example:

  |     ra   |    dec   |   sao   |      v   |    sptype        |
  |  double  | double   |   int   |    double|     char         |
  |    unit  |   unit   |   unit  |    unit  |     unit         |
  |    null  |   null   |   -999  |  -999.99 |     null         |
    2.09708   29.09056     73765    2.06000   B8IVpMnHg
    1.09708   19.09056      -999    -999.99   null
IRSA's table library interprets

Data Units:

IPAC format table allows a table provider to specify an unit for a column. An unit can be a character string, but use of tabs in front, between, or behind a unit string are strictly forbidden. 
  |     ra   |    dec   |   ratio |
  |  double  | double   |   int   |
  |  degree  |  degree  |         |
  |    null  |   null   |   -999  |
    2.09708   29.09056     73765   
    1.09708   19.09056      -999
Without unit string is treated as unitless.


 

Examples of properly formed tables:

Boundaries of Column Data:

IPAC table format allows the following: 
|  column1 |  column2 | column3 | column4  |    column5       |   
|  double  |  double  |   int   |   double |     char         | 
 1111111111 2222222222 333333333 4444444444 555555555555555555
This example displays the data boundaries for every column. The value with character "1" defines the data boundary for column1, "2" for column2, and so on.

Examples: