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.
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
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-$mag
rv
). 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
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