This document provides a complete design description of the Space-Time Coordinate (STC) metadata for the Virtual Observatory. It explains the various components, highlights some implementation considerations, presents a complete set of UML diagrams, and discusses the relation between STC and certain other parts of the Data Model. Two serializations are discussed: XML Schema (STC-X) and String (STC-S); the former is an integral part of this Recommendation.

Status of This Document

This document has been produced by the Data Model Working Group.
It has been reviewed by IVOA Members and other interested parties, and has been endorsed by the IVOA Executive Committee as an IVOA Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from another document. IVOA's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability inside the Astronomical Community.

A list of current IVOA Recommendations and other technical documents can be found at http://www.ivoa.net/Documents/.

Acknowledgements

I gratefully acknowledge many helpful discussions with Wil O’Mullane, Alex Szalay, Jonathan McDowell, Ray Plante, Ed Shaya, Pat Dowler, David Berry, Anita Richards, Steve Allen, Gerard Lemson, Tamas Budavari, François Bonnarel, and many others. I am indebted to SAO, ULP, CDS, and the NSF NVO grant for support.

Contents

1 Introduction 5

2 Justification and Scope 6

3 Requirements and Use-Context 8

4 Design 9

4.1 The Metadata Components 9

4.2 Generic Coordinates 10

4.2.1 Coordinate System (CoordSys) 10

4.2.1.1 Coordinate Frame (CoordFrame) 10

4.2.1.2 Coordinate Reference Frame (CoordRefFrame) 10

4.2.1.3 Coordinate Reference Position (CoordRefPos) 11

4.2.1.4 Coordinate Flavor (CoordFlavor) 11

4.2.2 Coordinates (Coords) 11

4.2.2.1 Coordinate 11

4.2.3 Coordinate Area (CoordArea) 13

4.2.3.1 ScalarInterval 13

4.2.3.2 Multi-dimensional Areas 13

4.3 Pixel Coordinates 13

4.3.1 Pixel Coordinate System 14

4.3.2 Pixel Coordinates 14

4.3.3 Pixel Coordinate Area 14

4.4 Astronomical Coordinates 14

4.4.1 AstroCoordSystem 14

4.4.1.1 TimeFrame 14

Table 1. Standard Reference Positions 15

Table 2. Timescales 17

4.4.1.2 SpaceFrame 18

Table 3. Standard Reference Frames 20

Table 4. Projection Types 22

4.4.1.3 SpectralFrame 23

4.4.1.4 RedshiftFrame 23

4.4.2 AstroCoords 24

4.4.2.1 TimeCoord 25

4.4.2.2 SpatialCoord 26

4.4.2.3 SpectralCoord 27

4.4.2.4 RedshiftCoord 27

4.4.3 AstroCoordArea 27

4.4.3.1 TimeInterval 28

4.4.3.2 SpatialInterval 28

4.4.3.3 VelocityInterval 29

4.4.3.4 SpectralInterval 29

4.4.3.5 RedshiftInterval 29

4.5.1.8 ConvexHull 31

4.5.1.9 SkyIndex 32

4.5.2 Operations 32

4.5.2.1 Intersection 32

4.5.2.2 Union 32

4.5.2.3 Negation 32

4.5.2.4 Difference 32

5 Projection and Transformation 32

6 Implementation 33

6.1 Implementation Requirements 33

6.1.1 Generic Coordinates 33

6.1.1.1 Coordinate System 33

6.1.1.2 Coordinates 34

6.1.1.3 Coordinate Area 34

6.1.2 Astronomical Coordinates 35

6.1.2.1 Astronomical Coordinate System 35

6.1.2.2 Astronomical Coordinates 36

6.1.2.3 Astronomical Coordinate Area 37

6.1.3 Pixel Coordinates 37

6.1.3.1 Pixel Coordinate System 37

6.1.3.2 Pixel Coordinates 38

6.1.3.3 Pixel Coordinate Area 38

6.1.4 Observational Metadata 39

6.2 STC-X: XML Schema Implementation 39

6.2.1 Referencing Mechanism 39

6.2.2 Versioning 40

6.3 STC-S 41

7 Conclusion and Usage Notes 41

7.1 Methods 41

7.2 Usage 42

7.2.1 Resource Profile 42

7.2.2 Query Constraint 42

7.2.3 Catalog Entry 42

7.2.4 Observational Data 43

Appendix A: UML Representation 43

Appendix B: Examples 56

B.1 STCResourceProfile for Chandra X-ray Observatory Data Archive 56

B.2 Blue M81 Image from KPNO 58

B.3 M81 Image Using Xlink References 62

B.4 A Coordinate System with an Unusual Reference Position 63

B.5 Query Specification 64

B.6 Arecibo Survey Profile 66

B.7 Arecibo Survey Query 72

B.8 A Galaxy Catalog 74

B.9 Using a FITS File 78

B.10 Orbit Ephemeris 82

B.11 Coordinate Table 86

B.12 Time Series 88

B.13 Event List 90

Appendix C: Standard Libraries 103

C.1 Standard Coordinate Systems 103

Table 6. Library of Standard Coordinate Systems 103

C.2 Observatory Locations 105

Table 7. Library of Observatory Locations 105

Appendix D: Changes from Previous Versions 107

References 109

1 Introduction

This document attempts to explain and document the design and implementation of the Space-Time (and related coordinate axes) metadata for the Virtual Observatory. The concepts represented in this model are not particularly profound. We need to allow users to specify the spatial coordinates they work in; these will, for most astronomical users, be some flavor of equatorial coordinates. However, we also need to be cognizant of the many variations that exist, not only in terms of different equatorial systems, either from historical collections (FK1-4) or in the uses of Galactic or ecliptic coordinates, but also geographic, barycentric, planetocentric, and instrumental detector coordinates, most of them in spherical as well as Cartesian form. In addition, high-accuracy requirements and special situations such as spacecraft-based observatories create the need for specifying the origin of such coordinate frames – in most cases the location of the observatory. The same is true for time and spectral coordinates: for many applications it may not matter, but there are situations where it is crucial to know what timescale was used, where time was measured, or what inertial standard of rest was used to express the frequency.

What this amounts to is that for spatial coordinates we want to know the coordinate system (its type and orientation) and the origin that were used, for time the timescale (UTC, TT, TAI, TDB, etc.) and the spatial reference position, for the spectral coordinate the origin in phase space, and for redshifts (Doppler velocity)[1] the definition as well as the phase space origin. In the past, many of these particulars were obvious to the sub-communities in which data were collected and distributed, but in the context of the VO we cannot assume anymore that these “obvious defaults” are indeed obvious (or even known) and we have to be explicit about our default assumptions. The issue here is that no single set of defaults is intuitive anymore for the entire community of users; and defaults that are not intuitive are too dangerous to use. Nevertheless, there are a few common coordinate systems that will serve the bulk of our data and we will make an effort to make their use as simple as possible.

An added complication is that users need to be able to specify the transformation between coordinate systems, not only for custom systems, but also, for instance, between the sky and a detector, or between a world coordinate system and a pixel coordinate system, analogous to the FITS WCS standards.

Much of the seemingly complicated content in this design is necessitated by three requirements, but can be ignored for more traditional astronomical use. Those requirements are that it (a) support the inclusion of planetary data, (b) allow the definition of arbitrary coordinate orientations, and (c) be extensible.

In order to make this specification optimally useful for the VO, we have generalized the Coordinate System concept and we have added a generic Coordinate Frame. A Coordinate System consists of one or more Coordinate Frames. A Coordinate Frame is usually defined by a Coordinate Reference Frame (the “direction” of the axes, if you like) and a Coordinate Reference Position (the “origin”). Most Coordinate Frames will be one-dimensional, but Spatial Frames may have up to three dimensions and Pixel Frames may have up to three, while certain other generic frames may also be multi-dimensional (e.g., Visibility with amplitude/phase or sine/cosine). Derived from these are the AstroCoordSystem and the time, space, redshift, spectral frames that together make up the Space-Time Coordinate (STC) system. Coordinate and Coordinate Area also have generic as well as Astro versions. We shall use “STC” as a proper name in this document which will lead to terms like “STC coordinates”. Although we agree that such usage is linguistically deplorable, we will use it nevertheless because of the clarity it provides.

We present two implementations of STC. The fundamental implementation is provided in the XML schema and is known as STC-X; this implementation is an integral part of this standard. A string implementation, based on STC-X, is known as STC-S. A Utypes implementation will be specified in a separate document.

There are six companion files to this document:

http://www.ivoa.net/xml/STC/v1.30
is the schema defining the XML implementation STC-X.
http://www.ivoa.net/Documents/latest/STC-Model.html
is an IVOA Note clarifying the STC model and may serve as a glossary.
http://www.ivoa.net/Documents/latest/STC-X.html
is an IVOA Note clarifying the STC-X (XML) implementation.
http://hea-www.harvard.edu/~arots/nvometa/STC/
contains more detailed documentation on the STC schema.
http://www.ivoa.net/Documents/latest/STC-S.html
is an IVOA Note clarifying the STC-S (string) implementation.
http://www.ivoa.net/xml/Xlink/xlink.xsd
is the standard Xlink schema.

The schema is fully up-to-date.

In the following sections we shall discuss the justification and scope for this metadata specification, the requirements and use context, a detailed design description, and some implementation considerations. Some concepts are only provided in their simplest form and we expect that more sophisticated classes will be derived (and will fit in seamlessly) as work progresses. The emphasis of this document is on the framework of the STC metadata.

2 Justification and Scope

Before we plunge into the requirements and design of these metadata structures, it may be helpful to discuss what is driving this exercise and to provide some context to the design. Our intent in this is to explain why the design needs to be fully general and extensible, leading to a certain level of complexity.

The basic justification for considering the following coordinate axes in a single metadata specification is that they are closely intertwined:

Space (including its time-derivatives, i.e., velocities)
Time
Spectral (frequency, wavelength, energy)
Redshift (Doppler velocity)

It should be emphasized that the STC design distinguishes between the spectral coordinate and the redshift coordinate (one might, after all, have to deal with a dataset containing Doppler velocities measured in different parts of the spectrum) and between redshifts and velocities (the latter are physical quantities – derivatives of spatial positions; the former represent a spectral property that is transformed via one of several formalisms to what is commonly referred to as a Doppler velocity – when we get to relativistic situations the connection with physical velocities becomes tenuous). In the presence of a redshift coordinate, the values of a spectral coordinate, if present, will contain rest frequencies. Please note that the term Redshift is to be taken generically and really stands for Dopplershift.

We shall refer to these as the STC coordinates. The issue is that time is bound to a position and positions are time-variable. Similarly, spectral and redshift data are tied to reference frames that may or may not be time-variable.

In the past, most data archives have not been extremely concerned with dotting every i and crossing every t, in a meticulous specification of all the details of all coordinate axes. They assumed sets of coordinate system-related defaults. Such context-dependent defaults are quite acceptable: issues are generally well-defined, obvious, and clear for single-observatory observations, even when not all is explicitly specified. However, there are no global defaults in the VO. All implicit assumptions need to be made explicit since they will not be “obvious” anymore. One must be able to transform the coordinates of two observations to a common coordinate system; this means that every little tidbit of information needs to be documented in the metadata.

Here are some simple examples of situations and questions that need an answer, when such context-dependent defaults do not work anymore:

Are Doppler velocities optical or radio?
What is the spatial reference position for the time stamps; if corrected for pathlength, what direction was assumed?
Does “J2000” mean “FK5/J2000” or “ICRS”?
At which spatial position was this observation made?
How can we get information on Galactic background objects from solar system observations, and vice versa?

Reality dictates, though, that we allow for cases where these values are simply unknown. In the XML implementation nillable elements that are nil should be interpreted as unknown values; the burden is then on the client to determine and adopt a sensible default value. This holds true for elements named “UNKNOWN” as well. We sincerely hope that the existence of such nillable and UNKNOWN

elements will not be an excuse to provide incomplete metadata in cases where the values are known.

This document defines the metadata items (and their structure) that specify coordinate properties in the VO. It identifies four major contexts in which these metadata play a crucial role and it shows how the metadata description can be constructed in these contexts, in a form that is preferred from the perspective of STC. However, the precise syntax of the incorporation of the STC metadata in the various VO interfaces and applications is left to their controlling documents.

3 Requirements and Use-Context

The top-level requirement for the design of the Space-Time Coordinate metadata can be formulated in a very simple way. It is that they:

provide sufficient and necessary information
are self-consistent

That is really all. However, to fit it into the larger VO Data Model context, we should leverage two more requirements:

the system should be extensible to include other coordinates and accommodate coordinate metadata descriptions that include axes other than the STC ones
it must be possible to define relocatable frames to accommodate, for instance, simulation data

From this one can derive secondary requirements: the metadata must include complete descriptions of the following three concepts:

the coordinate frames that anchor the STC coordinate axes, collectively referred to as the Coordinate System
a specific position in these frames, i.e., a coordinate object, that includes not only coordinate values, but also essential attributes such as errors and resolutions
the volume in coordinate space that is taken up by the data object that these metadata are attached to

In all, there are four different contexts for the use of the STC metadata:

STC Resource profile – to specify the spatial, temporal, redshift, spectral coverage of a data collection which is ultimately used by clients to determine whether or not the resource is of interest for their purposes
Query – to specify the STC constraints of a particular request
Catalog information – clearly, the response to a catalog query may contain coordinate information (e.g., positions), but it should also contain coverage information: specifically, the intersection of the catalog’s coverage and the query’s STC constraints
Observational data – here we need the volume in coordinate space that is occupied by the observational data, as well as the coordinates of the observatory; note that these may not necessarily be given in the same Coordinate System; a Pixel Coordinate System is needed for pixelated data

We will return to the use of STC in these contexts in Section 7. As commented before, the emphasis of this document is on the structure of the STC metadata. Hence, though the classes and attributes are laid out in detail, little is said about methods.

Notwithstanding our emphasis on the necessity of the completeness of STC metadata, it will be possible for servers to provide incomplete metadata. The universal default rule in STC is:

Any missing component in STC metadata shall be considered to have the value UNKNOWN. It is up to the client to decide whether it is willing to accept such metadata and to assign a suitable default value.

For detailed implementation requirements, see Section 6.1.

4 Design

It may be helpful to refer to the UML diagrams in Appendix A: UML Representation, while reading this section. The detailed implementation requirements that follow from this design are presented in Section 6.1.

An important part of the XML implementation is the referencing mechanism; it is described in Section 6.2.1. In addition, all entities described in this section, and their individual components, MAY optionally contain a UCD.

4.1 The Metadata Components

There are three metadata components in the design, as already noted in the derived requirements:

Coordinate system
This object contains the coordinate frames that together define a complete coordinate system. There may be one or more per document.
Coordinate values
This is an object that specifies a specific position in the space defined by the coordinate system it refers to. The object contains values, units, errors, resolution, size, and pixel size, though not all of these need be present.
Coordinate areas or ranges
This is an object that defines a volume in the coordinate space specified by the coordinate system it refers to. Regions are a special case, specifically designed for 2-D (and 3-D unit-sphere) spatial coordinates.

4.2 Generic Coordinates

Generic coordinates are primarily intended for all coordinate axes that are not temporal, spatial, spectral, redshift, or pixel-like.

4.2.1 Coordinate System (CoordSys)

The CoordSys class is nothing more than a collection of one or more Coordinate Frames, where each frame describes a set of one or more coordinate axes that belong together. A CoordSys MUST contain at least one Coordinate Frame.

4.2.1.1 Coordinate Frame (CoordFrame)

A CoordFrame object provides the metadata about one or more coordinate axes. Typically, it consists of a reference frame and a reference position, as well as a coordinate “flavor”, in particular for multi-dimensional frames. Usually, we will be dealing with one axis. The three exceptions are the spatial frame (which may control up to three position coordinate axes, as well as their time-derivatives – velocity), the pixel frame (which may, to support these spatial axes, also contain up to three axes), and certain generic axes (e.g., amplitude and phase, or polarization percentage and angle). In the XML schema CoordFrame is really the base class for coordinate frames. To ensure its full generality, this base class should only contain a name. Real-life coordinate frames should be derived from this class. If the name defines the coordinate unambiguously (e.g., “FluxDensity”), no further specification may be needed. A frame_id is required for all but the astronomical frames, in order to allow tying coordinates to frames.

If the Coordinate Frame is defined as a transformation from a known coordinate system, that transformation is specified through the Coordinate Reference Frame and the Coordinate Reference Position. The frame’s structure is defined by the Coordinate Flavor.

4.2.1.2 Coordinate Reference Frame (CoordRefFrame)

The reference frame relates the Coordinate Frame to a known frame. There are three basic types of reference frames: scalar, Cartesian (2-D or 3-D), and spherical.

4.2.1.2.1 Scalar Reference Frame

This is the simplest case, only containing a scale factor and a projection. The projection may be linear or logarithmic.

4.2.1.2.2 Cartesian Reference Frame

The 2-D or 3-D Cartesian reference frame may specify a projection and a transform. The latter may consist of a set of scale-and-rotate parameters or a proper transformation matrix. The projections include a list of spherical-to-Cartesian projections (see Table 4).

4.2.1.2.3 Spherical Reference Frame

The transformations for spherical coordinate systems are specified through a pole and an X-axis direction, expressed as coordinates in another, known spherical coordinate frame.

4.2.1.3 Coordinate Reference Position (CoordRefPos)

The Coordinate Reference Position specifies the origin of the Coordinate Frame and thereby completes the transformation.

4.2.1.4 Coordinate Flavor (CoordFlavor)

The Coordinate Flavor specifies the number of axes in the coordinate frame (1, 2, or 3) and the structure of the coordinate system: Cartesian, Spherical, Polar, UnitSphere, or Healpix^x. The Healpix specification includes the parameters H and K (with default values 4 and 3, respectively). Handedness (“left” or “right”) is well defined for known coordinate frames, but is an optional attribute for the benefit of generic and custom frames.

4.2.2 Coordinates (Coords)

The Coords object specifies a particular position in coordinate space. It requires a reference (IDREF in the XML implementation) to a CoordSys object and it is made up of one or more Coordinate objects, corresponding to the Coordinate Frames defined in the Coordinate System. All objects are optional. However, in order to constitute a meaningful Coords object, one would expect at least one of the Coordinate objects to be present.

4.2.2.1 Coordinate

A Coordinate is an aggregate of up to 6 components: CoordName, CoordValue, CoordError, CoordResolution, CoordSize, and CoordPixSize. Of these, only CoordName is a member of the Coordinate base class. The others, which in their simplest forms consist of a scalar numerical Value, are all optional, though one may doubt whether a Coordinate object that contains none of these has any meaning. Although at first sight it would seem that at least CoordValue is indispensable, we shall show that there are legitimate cases where the value may be absent. Coordinate has a single Unit attribute that applies to all components, as well as optional Unit attributes for the individual components that would override the global one. Classes that are derived from Coordinate may differ in the data types of the objects, their structure and meaning, as well as restrict allowable values for Unit. There are currently two derived classes that have only a Name and a Value: StringCoordinate and PixelCoordinate.

The numeric elements, other than the Coordinate Value, may appear singly or in pairs. In the former case it will be obvious that a single specific value is indicated. In the latter case the pair indicates a range of values.

A generic Coordinate SHALL contain a reference to a specific Coordinate Frame.

A numeric Coordinate may be 1-, 2-, or 3-dimensional; all components of a Coordinate object SHALL be consistent in their dimensionality.

4.2.2.1.1 Name

This member of Coordinate is a simple string that acts as a label; usage should indicate whether this should be restricted to an enumerated list in a future version.

4.2.2.1.2 Value

The value of the Coordinate consists of a scalar numerical, a 2- or 3-dimensional vector, or a string value and a Unit string.

4.2.2.1.3 Error

Again, this consists of a scalar Value for scalar coordinates, representing an rms[2] error. However, we expect a variety of derived classes to appear with more sophisticated error descriptions. For multi-dimensional coordinates more information is required: error circle, error ellipse, error matrix, and their 3-D equivalents.

4.2.2.1.4 Resolution

The resolution along the Coordinate is expressed as a FWHM [3] Value. In cases where this is a poor description, a more sophisticated class should be derived. For multi-dimensional coordinates more information is required: circle, ellipse, matrix, and their 3-D equivalents.

4.2.2.1.5 Size

The size along the Coordinate is also expressed as a FWHM3 Value, though one might expect derived classes with more precise definitions (e.g., Holmberg[4] diameter). This object is used in three contexts: in a resource profile it indicates the typical size (e.g., FOV[5]) of datasets in the resource; in queries it serves the same purpose; and in catalog datasets it allows the server to provide Coordinate positions of objects as well as their sizes. For multi-dimensional coordinates more information is required: circle, ellipse, matrix, and their 3-D equivalents.

4.2.2.1.6 PixSize

The pixel size (scalar Value) is often a useful figure to characterize resources, queries, and datasets, even if it only provides a typical value. It is intended to be a quick characterization and should not replace a proper PixelCoords and PixelCoordSys pair that rigorously defines the transformation between world coordinates and pixel space. For multi-dimensional coordinates more information is required: pixel size vectors, position angles, CD matrix.

4.2.3 Coordinate Area (CoordArea)

The Coordinate Area class defines the volume in coordinate space that is occupied by the object it is attached to. It is an aggregate of one or more ranges in individual coordinates and is required to have a reference (IDREF in the XML implementation) to a CoordSys. Multiple ranges along each coordinate axis are OR-ed together; the ranges of different axes are logically AND-ed together.

4.2.3.1 ScalarInterval

A ScalarInterval consists of a LoLimit and/or a HiLimit, both of which contain a double precision value and a unit. Note that they do not both have to be present, but at least one of them needs to be. If only one is present, an upper or lower limit (rather than an interval) is indicated. ScalarInterval has Boolean attributes LoInclude and HiInclude and a FillFactor attribute with a value between 0 and 1 that indicates what fraction of the interval is actually covered by the data.

4.2.3.2 Multi-dimensional Areas

Rectangles or boxes are the equivalent of the Scalar Interval in two and three dimensions. The rules and properties are the same. In addition, Spheres are added in three dimensions and Regions in two. The latter are described in more detail in Section 4.5.

4.3 Pixel Coordinates

The three top-level classes (PixelCoordSys, PixelCoords, PixelCoordArea) are derived from their generic counterparts and therefore contain all the (generic) elements enumerated in the previous section. In addition, they contain what is described below.

4.3.1 Pixel Coordinate System

The Pixel Frames in PixelCoordSys are like their generic numeric counterparts (1-D, 2-D, or 3-D; see Section 4.2.1.1), with the addition of two important components: axisorder (for 2-D and 3-D) and ReferencePixel. The former is required because it will not be a priori obvious what the order of the pixel axes is, even though there is a link through the frame_id. The Reference Pixel is required since pixel frames typically do not put their origin at zero.

Note that a PixelCoordSys is a collection of Pixel Frames, where the dimensionality needs to correspond with the number of frames and their dimensionality in physical space. The sum of all Pixel Frame axes should equal the dimensionality of the associated pixel array. For instance, a three-axis pixel grid mapping RA, Dec, and Doppler velocity should be built up from two frames: a 2-dimensional frame that corresponds with the 2-D spatial frame, and a scalar frame that corresponds with the redshift coordinate; the axis order attributes tell which one is which.

4.3.2 Pixel Coordinates

Pixel coordinates are simpler than others in that they only have a name and a value, and do not have units associated with them.

4.3.3 Pixel Coordinate Area

The Pixel Coordinate Area has the same properties as the generic Coordinate Area (see Section 4.2.3).

4.4 Astronomical Coordinates

The three top-level classes (AstroCoordSystem, AstroCoords, AstroCoordArea) are derived from their generic counterparts and therefore may contain all the (generic) elements enumerated in Section 4.2. In addition, they contain what is described below.

4.4.1 AstroCoordSystem

The AstroCoordSystem is derived from CoordSys. It still is a collection of coordinate frames, but it SHOULD contain one or more specific frame classes derived from the CoordFrame base class, in addition to zero or more additional generic frames. These special frames are TimeFrame, SpaceFrame, SpectralFrame, and RedshiftFrame. See Appendix C.1 for examples.

4.4.1.1 TimeFrame

The Time Frame contains two or three objects: a reference position, a time scale (the equivalent of a reference frame), and, optionally, a time reference direction.

4.4.1.1.1 ReferencePosition

The Reference Coordinate Position is similar to the ones defined for generic coordinates (see Section 4.2.1.3), but in addition we have defined a number of Standard Reference Positions which have special meaning in an astronomical context.

The reference position, or spatial coordinate origin, may be chosen from a standard list of such origins (StdRefPosition) or specified as a particular coordinate position (CoordOrigin). In the latter case, one may nest the origins, but eventually they should be referenced to a known standard origin. The list of standard origins includes (see Table 1): GEOCENTER, BARYCENTER, HELIOCENTER, TOPOCENTER, LSR, GALACTIC_CENTER, LOCAL_GROUP_CENTER, EMBARYCENTER, MOON, MERCURY, VENUS, MARS, JUPITER, SATURN, URANUS, NEPTUNE, PLUTO, RELOCATABLE; additional values (e.g., planetary satellites, non-planet solar system objects) are allowed, provided they are identified in a referenced ephemeris or other authoritative source (see: Section 4.4.1.1.4). Ultimately, one must be able to tie the coordinate origin down to the geocenter, be it through a geographic position, an IAU resolution, an orbit ephemeris, or a solar system ephemeris – unless one deals with simulation data that have a RELOCATABLE origin. Planetary Ephemeris is required for any position related to a solar system entity other than the geocenter. ReferencePosition is a standard class that is being used for all four STC frames, though there are different restrictions for the four usages. For the Time Frame LSRK, LSRD, GALACTIC_CENTER, LOCAL_GROUP_CENTER, and RELOCATABLE are not allowed values; for simulations one may want to use a custom position (or “LOCAL”) at the origin of the relocatable spatial frame. TOPOCENTER refers to the location of the observatory, if appropriate. If there is no such location defined then a TOPOCENTER time reference position refers to the spatial reference position.

Table 1. Standard Reference Positions

Reference Position	Description	Comments
GEOCENTER	Center of the earth
BARYCENTER	Center of the solar system barycenter
HELIOCENTER	Center of the sun
TOPOCENTER	“Local”; in most cases this will mean: the location of the telescope
LSR or LSRK	Kinematic Local Standard of Rest: 20 km s^-1 in the direction of GALACTIC_II(56,+23)	Only to be used for redshifts and Doppler velocities, and spectral coordinate
LSRD	Dynamic Local Standard of Rest: 16.6 km s^-1 in the direction of GALACTIC_II(53,+25)	Only to be used for redshifts and Doppler velocities, and spectral coordinate
GALACTIC_CENTER	Center of the Galaxy: 220 km s^-1 in the direction of GALACTIC_II(90,0) wrt LSRD
LOCAL_GROUP_CENTER	Center of the Local Group: 300 km s^-1 in the direction of GALACTIC_II(90,0) wrt BARYCENTER	Only to be used for redshifts and Doppler velocities, and spectral coordinate
EMBARYCENTER	Earth-moon barycenter
MOON	Center of the moon
MERCURY	Center of Mercury
VENUS	Center of Venus
MARS	Center of Mars
JUPITER	Center of Jupiter
SATURN	Center of Saturn
URANUS	Center of Uranus
NEPTUNE	Center of Neptune
PLUTO	Center of Pluto
RELOCATABLE	Relocatable center; for simulations	Only to be used for spatial coordinates
UNKNOWNRefPos	Unknown reference position	Only to be used as a last resort. The client is responsible for assigning a suitable default

4.4.1.1.2 TimeScale

The time scale must be chosen from among the list recognized by the IAU (see Table 2): TT, TDT, ET, TAI, IAT, UTC, GPS, TDB, TEB, TCG, TCB, LST. TT is the default; TDT and ET are obsolete synonyms for TT; IAT is an unofficial synonym for TAI; and use of LST is to be discouraged. At some point other time scales may need to be added as they become recognized, such as planet- or moon-based time scales. In most cases where TEB is specified, the likely intent was TDB, so TEB may be considered a synonym of TDB; its use requires the presence of a Planetary Ephemeris. For further details, see Seidelmann & Fukushima (1992)[i] and Standish (1998)[ii].

We will allow the value LOCAL, only to be used with RELOCATABLE space frames (see: Section 4.4.1.1.1), specifically for simulations.

For a handy explanation of time scales, see: http://tycho.usno.navy.mil/systime.html

For a glossary of fundamental astronomy terms, see: http://syrte.obspm.fr/iauWGnfa/NFA5_B.html

In the XML implementations the Timescale element is nillable.

Table 2. Timescales

Timescale	Description	Comments
TT	Terrestrial Time
TDT	Terrestrial Dynamic Time; synonym for TT
ET	Ephemeris Time: predecessor of, and continuous with, TT
TAI	International Atomic Time; 32.184 s behind TT
IAT	Synonym for TAI
UTC	Coordinated Universal Time; 32 s behind TAI in 2000-2005	Includes leap seconds Pre-1972 times will be assumed to be UT/GMT
GPS	Global Positioning System’s time scale; 19 s behind TAI, 51.184 s behind TT	This time scale may become important in the future
TDB	Barycentric Dynamical Time; synchronous with TT, except for variations in earth’s orbital motion	Requires specification of the solar system and planetary ephemeris used
TEB	Barycentric Ephemeris Time; independent variable in solar system ephemeris, linear function of TT	In most cases where TEB is specified, TDB is really the one used
TCG	Geocentric Coordinate Time; properly relativistic time, running a factor 7∙10^-10 faster than TT
TCB	Barycentric Coordinate Time; properly relativistic time, running a factor 1.5∙10^-8 faster than TDB
LST	Local Siderial Time	Ground-based observations only
LOCAL	“Local” time	Only to be used for simulations, in conjunction with RELOCATABLE spatial coordinates

4.4.1.1.3 TimeRefDirection

If the Time Frame’s Reference Position is not TOPOCENTER, times have clearly been transformed from observed time at the location where the observation was made to some other spatial location. In order to effect such a transformation, a direction of origin must have been assumed for the observed phenomenon; that direction is given in TimeRefDirection.

4.4.1.1.4 Planetary ephemeris (if needed)

The planetary ephemeris object PlanetaryEphem indicates which solar system ephemeris was used in the AstroCoordSystem. In general, this will be JPL’s DE200 or DE405 (default)[iii]. It should only be present if a solar system ephemeris was used, for instance because of a planet-based ReferencePosition or the application of barycenter corrections. In addition, the information in Sections 7.2-7.5 of the Explanatory Supplement to the Astronomical Almanacⁱⁱⁱ may be considered a known authoritative source for t