This part of the document comprises reference material describing the ACL configuration file and the Tab-Separated Table (TST) format. Most of the material is adapted from Section 2 of Allan Brighton’s Astronomical Catalogue Library User Manual[2].
This section describes the format of the ACL configuration file. When you refer to it you might find it useful to
have to hand a copy of either simpleconfig.cfg or some other configuration file.
An ACL configuration file mediates the interaction between a client such as GAIA and a remote server. The configuration file comprises a list of one or more databases, giving details for each. Usually each ‘database’ will be a simple astronomical catalogue. However, other alternatives are possible: archives, name servers, etc. Consequently, in this section the generic term ‘database’ is used to denote each entry. Also, it is individual databases, not servers, which are listed in the configuration file: some servers might give access to more than one database. The details supplied for each database are things like: its URL, the type of queries supported, the name that will be used to describe it to users etc. The client reads the configuration file and the databases listed become the ones that it knows about.
By convention, configuration files have file-type ‘.cfg’. They are ASCII text files which may be created and
modified with a text editor. Their basic syntax is as follows.
#’ are considered to be comments and are ignored.
\’ (backslash) are continued on the next line.
serv_type.
"’) and separated by one or more
space characters. Alternatively, curly brackets (‘{ }’) may be used instead of double-quotes.
:’).
$’).
The entry for an individual database in a configuration file comprises some of the following keywords. The
entry for the database must begin with the serv_type keyword. Other keywords can occur in any order. The
keywords are optional unless otherwise indicated. The keywords are case-sensitive and must be specified
entirely in lower case.
serv_type long_name short_name database@institution
where database is an abbreviation for the database and institution a standardised abbreviation for the institution where the on-line version is located. By convention institution has three or four characters; some common values are listed in Table 1.
| Abbreviation | Institution |
cadc | Canadian Astronomy Data Centre, Dominion Astrophysical Observatory |
eso | European Southern Observatory, Garching bei München |
lei | Department of Physics and Astronomy, University of Leicester |
roe | Royal Observatory Edinburgh |
url symbol copyright search_cols sort_cols sort_order increasing and
descreasing.
show_cols show_cols list is specified
then by default only the columns in the list will be displayed. Also the order of the list defines the order in
which the columns should be displayed.
id_col ra_col dec_col x_col y_col is_tcs help backup1 url
keyword does not respond.
backup2 url and backup1 keywords do not respond.
For keywords id_col, ra_col, dec_col, x_col and y_col the number of a column is defined as its sequence
number in the list of column names which defines the columns in a TST table (see Section 11 and Figure 2). The
first column is numbered zero. This sequence number is sometimes referred to as the ‘column
index’.
The types of database which may be specified for keyword serv_type are as follows. If an unrecognised type is
specified it will be ignored (to permit future extensions).
catalog archive catalog’, but the table returned may
contain special columns whose values are URLs giving access to ‘bulk data’ (images, spectra,
time-series etc) for the selected objects. See Section 11.1 for details of these special columns.
namesvr simpleconfig.cfg for an example of a namesvr entry.
imagesvr local directory url keyword gives
the URL of the destination configuration file. The term ‘directory’ comes from making an analogy
with an hierachical file system. See configuration file simpleconfig.cfg for an example.
The url keyword prescribes how the client should access a remote server to query a database. Following the
usual conventions for a CGI gateway it consists of the URL corresponding to the script which constitutes the
server, followed by a ‘?’ and then a string defining the query passed to the server. The query string consists of
simple characters and ‘tokens’. The tokens start with a ‘%’ character. When a client makes a query the tokens are
replaced with values which correspond to the individual query and the resulting string is sent to the server. An
example query string for a server which provides circular area searches on a single catalogue might
be:
ra=%ra&dec=%dec&radius=%r2
which contains the tokens %ra, %dec and %r2. The client might substitute them to yield:
The format of the query string must correspond to that expected by the server. This restriction aside,
considerable freedom is allowed in the format of the query string. See configuration file simpleconfig.cfg for
examples. The complete list of the permitted tokens is as follows.
%ra %dec %x %y %r %r1 %r2 %w %h %m1 %m2 %m %n %cols %id namesvr (‘name server’) database.
%mime-type get command.
%sort %sortorder increasing
and decreasing.
%cond By default databases are assumed to contain columns of Right Ascension and Declination on which they can be searched. However, some databases do not contain such coordinates, but rather have Cartesian positions. Typically such positions occur in catalogues generated by detecting the objects present in a CCD direct image frame or a digitised photographic plate. The following rules apply.
ra’ and ‘dec’, respectively. Simply include the
tokens %ra and %dec in the query.
If a sexagesimal value is entered than a colon (‘:’) should be used as a separator. The coordinates should be for equinox and epoch J2000.
ra_col: -1
dec_col: -1
x_col: (sequence number of column holding
coordinate)
y_col: (sequence number of column holding
coordinate)
Setting ra_col and dec_col to -1 indicates that columns of Right Ascension and Declination are not
available.
%r %r1 %r2 %w %h
The alternatives for their units are:
To permit range queries on one or more columns of a database the keyword search_cols should be included in
the entry for the database in the configuration file and the %cond keyword should be included in the query part
of its url keyword. These items have the following syntax.
search_cols keyword search_cols:column-name-1 minimum-prompt-1 maximum-prompt-1 :
column-name-2 minimum-prompt-2 maximum-prompt-2 …
The client uses the minimum and maximum prompts when soliciting the extrema of the required range from the user. An example might be
search_cols: mag "Bright limit" "Faint limit" : \
b_v "Minimum colour" "Maximum colour"
%cond token url keyword and specifies any range search that is
supplied. The syntax of the values substututed into the %cond string is:
column-name-1 = minimum-value-1,maximum-value-1& column-name-2 =
minimum-value-2,maximum-value-2 …
When a search is specified column-name-n, minimum-value-n and maximum-value-n are substituted with respectively the column name, minimum value and maximum value. The server should process this string and return only rows that lie within the given ranges. An example of substituted query might be:
mag=1.0,2.0&b_v=0.1,0.3
The keyword symbol prescribes how objects in the returned table of values are to be displayed in finding charts,
image overlays etc. Considerable flexibility is allowed in the way that objects are plotted. In particular,
the two common types of cases which are conventionally used in atlases and finding charts are
supported:
The symbol keyword only prescribes how objects should be plotted in finding charts and image
overlays; it is not appropriate for scatter-plots where the two axes are not celestial coordinates or
positions. The syntax of the symbol keyword is:
symbol:column-names symbol-info size-expr :…
This triumavirate of items can be repeated an arbitrary number of times, with each occurence being separated
by a colon (‘:’). The meaning of each of the three items is as follows.
{ } ’). Alternatively, names which
contain spaces but not any characters which Tcl regards as special may be enclosed in double-quotes
(‘" "’).
image deg J2000 deg B1950 | Symbol | Scale and |
| rotate? | |
square | |
circle | |
triangle | |
cross | |
diamond | |
plus | |
ellipse | |
compass | |
line | |
arrow | |
| Colour | Name |
| default | (default) |
| red | red |
| green | green |
| blue | blue |
| cyan | cyan |
| magenta | magenta |
| yellow | yellow |
The default colour is the opposite of the plot background. Usually it will be black or white.
symbol-info prescribes the appearance of the symbol plotted. It is a list comprising the following items:
symbol colour ratio angle label condition
symbol is mandatory; the other items are optional.
true (or 1) then the object is plotted; if it
evaluates to false (or 0) it is not. By having a list of entries for the symbol keyword, each with a
different condition attached to the symbol-info item different symbols can be plotted for each object,
depending on the values of its column entries.
symbol: "" circle 12 symbol: mag circle 15-$mag mag).
symbol: mag {circle red} 15-$mag symbol: {a b pa} {ellipse red $a/$b $pa} {$a/3600.0 "deg J2000"} a and b respectively). The orientation is computed from position angle (pa). The
image size is computed in degrees from the semi-major axis, which is assumed to be in seconds of
arc.
symbol: {mag rv} {circle red "" "" "" $rv>0 } 15-$mag :\ {mag rv} {circle blue "" "" "" $rv<=0 } 15-$magrv). Objects with a positive radial velocity are shown in red, those with a
negative one in blue.
If a standard Tcl expression does not allow you to calculate the symbol size as you wish then you may be able to invoke your own Tcl procedure to perform the calculation. This facility is only available if you are using SkyCat as a client and is only likely to be useful with your own catalogues. An example might be:
symbol "rmag bmag" circle "[my_plot_proc $rmag $bmag]"
where you provide Tcl procedure my_plot_proc.
A Perl script is available to check the validity of configuration files. You can use it to check for errors in any configuration files that you have created or modified. It is included with the examples provided with this document as file:
/star/examples/ssn75/checkcfg
You can either run it from the examples directory or copy it to a convenient local directory. On non-Starlink systems you may need to edit the first line to correspond to wherever Perl is located on your system.
To use the script simply specify the name of the configuration file, optionally preceded by the appropriate directory specification, on the command line:
/star/examples/ssn75/checkcfg configuration-file-name
For example, to check a copy of the example configuration file supplied with this document (assuming that there is a copy in your current directory):
/star/examples/ssn75/checkcfg simpleconfig.cfg
If the configuration file is valid the checkcfg will display the message:
Configuration file parsed successfully.
Conversely, if there are problems with the configuration file then explanatory error messages are displayed.
Usually the number of the invalid line in the configuration file is included in the message. Note that checkcfg
is mostly checking for syntax errors; it does not, for example, check that any URLs specified are
valid.
This section gives a brief description of the tab-separated table (TST) format. ACL servers should return the list of selected objects in this format. Various packages, including GAIA, CURSA and Starbase can also read local files containing catalogues in this format. There are alternative descriptions of it in SUN/214[4], the Starbase FAQ4 and the Astronomical Catalogue Library User Manual[2].
TST format files are text files. They are usually generated by a remote server in response to a query from a local client. However, they could equally well be local files created with a text editor. Figure 2 shows a simple example of a tab-separated table. This example is available as file:
/star/examples/ssn75/simple.TAB
<tab>’. (Note that the first column, Id, is an
object name and hence its units are left blank. Thus, the CURSA-specific column-units: is
separated from the following <tab> character by only one or more spaces; see Section 11.3
for details of the CURSA extensions.) The description of the table and the table of values occupy the same file and the description occurs at the start of the file. Most of the description shown in Figure 2 is optional.
The first line of the description is a title. Lines beginning with a ‘#’ are comments which are ignored.
Parameter definitions start with the parameter name, and a colon (‘:’) is appended to the end of the name to
identify it as such. The rest of the line contains the parameter value. The name and value are the
only information stored for each parameter. The example contains two parameters: EQUINOX and
EPOCH.
Any remaining lines in the description (apart from the last two, which immediately precede the table of values) are free text.
The only mandatory items in the description are the two lines immediately before the table of values. The first
of these lines is the list of column names. Each name is separated by a single tab character (ASCII code nine;
strictly speaking the horizontal tab). In the figure tab characters are shown as ‘<tab>’; obviously a real
tab-separated table would contain actual tab characters instead. The name is the only mandatory information
stored for each column. The TST format places few restrictions on the column names: they can contain spaces,
special and punctuation characters etc. However, it is usually a prudent precaution to restrict column names to
contain only alphanumeric and underscore (‘_’) characters and to make the first character alphabetic. If these
precautions are observed then fewer problems are likely to occur if the table is subsequently converted to
another format or read by a variety of different clients. Remember that if you are writing a server
which returns a TST table via the Internet then you do not know which client will be used to access
it.
The line immediately after the list of column names indicates the end of the description and the start of the table. It consists solely of dashes and tab characters. By convention there are as many sequences of dashes as there are column names, each sequence is separated by a single tab character and each has the same number of dashes as there are characters in the corresponding column name.
In the table of values each row occupies a single line. Individual fields are separated by a single tab character. The fields occur in the same order as the corresponding column names.
The TST format has the following additional rules for special columns containing identifiers and celestial coordinates.
Id, ra and dec respectively.
id_col
ra_col
dec_col
The value of each parameter should be the number of the appropriate column or, if there is no such
column, -1. The column number is the sequence number of the column in the list of column names,
starting counting at zero.
:’) is used as the sexagesimal separator.
equinox and epoch respectively. The default value
if the equinox and epoch are not specified is J2000.0.
In addition to the basic TST format the following additional conventions apply to tables returned by ACL servers.
id_col, ra_col and dec_col are usually supplied as keywords in
the configuration file rather than parameters in the TST returned by the server. If a client writes
a table of retrieved objects as a local file in the TST format it should include these keywords as
parameters.
archives (see Section 10.2), may return tables containing
columns called more and preview. These columns are optional. However, if present they should
be used as follows.
more preview Some additional items can be added to the TST header information which provide additional information about
the catalogue and allow CURSA[3] to interpret it more precisely. These items begin with a ‘#’ character and thus
are TST comments. Consequently a catalogue which contains them remains perfectly standard and valid and
can be processed with software other than CURSA. The items are illustrated in Tables 1 and 2 and are as
follows.
#column-units: #column-types: #column-formats: | CURSA Data Type | Description | Standard |
| Fortran 77? | ||
| BYTE | Signed byte | No |
| WORD | Signed word | No |
| INTEGER | Signed integer | Yes |
| REAL | Single precision | Yes |
| DOUBLE | Double precision | Yes |
| LOGICAL | Logical | Yes |
| CHAR[] | Character string | Yes |
is the number of elements in the character string; it is a positive integer.
In all cases the items are listed in the order in which they occur in the table. There is no tab character between
#column-units:, #column-types: and #column-formats: and the following value. Values in the special TST
columns of Right Ascension and Declination (that is, those identified by the ra_col and dec_col
parameters) are always interpretted using the TST rules for representing angles rather than the CURSA
ones.
The first line of information returned by an ACL server should always be the MIME5 type:
Content-type: text/plain
This line is strictly speaking not part of the TST table and will be used by the client or Web browser to interpret the format of the data which follow.
Image servers differ from other types of ACL server in that they return a direct image or ‘pixel map’ of a region of sky rather than a catalogue of objects. The image is returned formatted as a FITS6 file which may optionally be compressed.
imagesvr. The region of sky required is specified by giving the central Right Ascension and
Declination (or
pixel position if celestial coordinates are not available), width and height. The usual tokens (see
Section 10.3):
%ra %dec %x %y %w %h
are included in a query string as part of a url keyword in the usual fashion. The tokens have their usual
meaning and units. An example configuration file entry for an image server is:
Content-type: image/x-gfits
| MIME type | Type of compression |
image/fits | uncompressed |
image/x-hfits | H compressed |
image/x-gfits | gzipped |
image/x-gstarbase | gzipped (alternative) |
image/x-cfits | UNIX compressed |
image/x-cstarbase | UNIX compressed (alternative) |
text/html | error message in HTML format |
The material in Part II is largely based on Section 2 of Allan Brighton’s Astronomical Catalogue Library User Manual[2]. Martin Bly, Allan Brighton, Peter Draper and Mike Read provided useful comments on the draft version of the document. Any mistakes, of course, are my own.
[1] M. Albrecht, M. Barylak, D. Durand, P. Fernique, A. Micol, F. Ochsenbein, F. Pasian,
B. Pirenne, D. Ponz and M. Wenger, 19 September 1996, Astronomical Server URL (Version 1.0).
See URL: http://vizier.u-strasbg.fr/doc/asu.html
[2] A. Brighton, 16 January 1998, Astronomical Catalog Library User Manual, issue 3.1 (document number GEN-SPE-ESO-19400-0949), European Southern Observatory Very Large Telescope Data Management Division.
[3] A.C. Davenhall, 25 July 2000, SUN/190.8: CURSA — Catalogue and Table Manipulation Applications, Starlink.
[4] P.W. Draper and N. Gray, 27 January 2000, SUN/214.7: GAIA — Graphical Astronomy and Image Analysis Tool, Starlink.
[5] I.S. Graham, The HTML Sourcebook, 1995 (John Wiley and Sons: New York).
[6] J.K.Ousterhout, 1994, Tcl and the Tk Toolkit (Addison-Wesley: Reading, Massachusetts).
[7] R.L. Schwartz, 1993, Learning Perl (O’Reilly and Associates Inc: Sebastopol, California).
[8] L. Wall and R. L. Schwartz, 1991, Programming Perl, (O’Reilly and Associates Inc: Sebastopol, California).
2The Tcl scripting language is described by its author, John Ousterhout, in his Tcl and the Tk Toolkit[6].
3The Tcl scripting language is described by its author, John Ousterhout, in his Tcl and the Tk Toolkit[6].
4http://cfa-www.harvard.edu/ john/starbase/FAQ.html
5Multipurpose Internet Mail Extensions. The MIME protocol was originally developed to allow non-text data to be included in e-mail messages and was subsequently adopted for use with HTTP.
6http://fits.gsfc.nasa.gov/fits_home.html