Space-Time Coordinate Metadata for the Virtual Observatory

Version 1.20

 

IVOA WG Internal Draft 2005-02-25

 

Working Group:

            http://www.ivoa.net/twiki/bin/view/IVOA/IvoaDataModel

Authors:

Arnold Rots – Harvard-Smithsonian Center for Astrophysics

 

 

Abstract

This document provides a complete design description of the Space-Time Coordinate 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.

 

Status of this document

This is a Working Group Internal Draft

 

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, and many others. I am indebted to SAO, ULP, CDS, and the NSF NVO grant for support.

 

Table of Contents

Space-Time Coordinate Metadata for the Virtual Observatory  1

Version 1.20  1

IVOA WG Internal Draft 2005-02-25  1

Abstract 1

Status of this document 1

Acknowledgements  1

1. Introduction  3

2. Justification and Scope  4

3. Requirements and Use-Context 5

4. Design  6

4.1 The Metadata Components  6

4.2 Coordinate System (CoordSys) 6

4.2.1 Coordinate Frame (CoordFrame) 6

4.3 Coordinates (Coords) 6

4.3.1 Coordinate  6

4.4 Coordinate Area (CoordArea) 8

4.4.1 ScalarInterval 8

4.5 AstroCoordSys  8

4.5.1 TimeFrame  8

Table 1. Standard Reference Positions  9

Table 2. Timescales  10

4.5.2 SpaceFrame  11

Table 3. Standard Reference Frames  12

4.5.3 SpectralFrame  14

4.5.4 RedshiftFrame  15

4.6 AstroCoords  15

4.6.1 TimeCoord  15

4.6.2 SpatialCoord  16

4.6.3 SpectralCoord  17

4.7 AstroCoordArea  17

4.7.1 TimeInterval 18

4.7.2 SpatialInterval 18

4.7.3 VelocityInterval 18

4.7.4 SpectralInterval 18

4.7.5 RedshiftInterval 18

4.8 Region  18

4.8.1 Shapes  19

4.8.2 Operations  21

5. Projection  21

6. Conclusion and Usage Notes  21

6.1 Methods  22

6.2 Usage  22

6.2.1 Resource Profile  22

6.2.2 Query Constraint 23

6.2.3 Catalog Entry  23

6.2.4 Observational Data  23

7. Implementation  23

7.1 XML Schema Implementation  23

7.1.1 Simplifications  24

7.2 LinearSTC   24

Appendix A – UML Representation  24

Appendix B – Examples  34

B.1 STCResourceProfile  34

B.2 Galaxy Catalog  36

B.3 ROSAT Image  39

B.4 Blue M81 Image from KPNO   42

B.5 Query Specification  45

Appendix C  -  XInclude Library of Coordinate Systems  47

Appendix D  -  Changes from Previous Versions  48

 

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. 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. Derived from these is the AstroCoordSys and the time, space, redshift, spectral frames that together make up the STC coordinate system. Coordinate and Coordinate Area also have generic as well as Astro versions. There are six companion files to this document:

 

The schemas are 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 ask 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 its alleged complexity.

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

 

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.

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:

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. The holds true for elements name “UNKNOWN”. 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.

 

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:

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

 

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

 

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

 

We will return to the use of STC in these contexts in Section 6. 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.

 

4. Design

It may be helpful to refer to the UML diagrams in the Appendix, while reading this section.

 

4.1 The Metadata Components

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

 

4.2 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.

 

4.2.1 Coordinate Frame (CoordFrame)

A CoordFrame object provides the metadata on one or more coordinate axes. Usually, we will be dealing with one axis. The exception is the spatial frame which may control up to three position coordinate axes, as well as their time-derivatives (velocity). 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.

 

4.3 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.3.1 Coordinate

A Coordinate is an aggregate of up to 6 objects: CoordName, CoordValue, CoordError, CoordResolution, CoordSize, and CoordPixSize. Of these, only CoordName is required to be present. 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. 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 in indicated. In the latter case the pair indicates a range of values.

 

4.3.1.1 CoordName

This required member of Coordinate is a simple string that acts as a label, presumably taken from a limited enumerated list

 

4.3.1.2 CoordValue

The value of the Coordinate consists of a scalar numerical or string value and a Unit string.

 

4.3.1.3 CoordError

Again, this consists of a scalar Value, representing an rms[1] error. However, we expect a variety of derived classes to appear with more sophisticated error descriptions. And clearly, the multi-dimensional coordinates require more information.

 

4.3.1.4 CoordResolution

The resolution along the Coordinate is expressed as a FWHM[2] Value. In cases where this is a poor description, one should derive a more sophisticated class.

 

4.3.1.5 CoordSize

The size along the Coordinate is also expressed as a FWHM2 Value, though one might expect derived classes with more precise definitions (e.g., Holmberg[3] diameter). This object is used in three contexts: in a resource profile it indicates the typical size (e.g., FOV[4]) 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.

 

4.3.1.6 CoordPixSize

The pixel size (scalar Value) is often a useful figure to characterize resources, queries, and datasets, even if it only provides a typical value.

 

4.4 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.4.1 ScalarInterval

A ScalarInterval consists of a LoLimit and/or a HiLimit, both of which contain a double 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 is indicated. ScalarInterval has Boolean attributes LoLimInclude and HiLimInclude 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.5 AstroCoordSys

The AstroCoordSys is derived from CoordSys. It still is a collection of coordinate frames, but it is required to contain specific frame classes derived from the CoordFrame base class, in addition to zero or more additional (generic) frames. The required frames are TimeFrame, SpaceFrame, and SpectralFrame; RedshiftFrame is optional.

 

4.5.1 TimeFrame

The Time Frame contains two or three objects: a reference position, a time scale, and, optionally, a time reference direction.

 

4.5.1.1 ReferencePosition

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.5.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 at the origin of the relocatable spatial frame.

 

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[K]

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

UNKNOWN

Unknown reference position

Only to be used as a last resort
The client is responsible for assigning a suitable default

 

 

4.5.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, 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 TDB is specified, the likely intent was TEB, so TDB may be considered a synonym of TEB; its use requires the presence of a Planetary Ephemeris. For further details, see Seidelmann & Fukushima (1992)[5] and Standish (1998)[6].

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

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_B3.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 2004

Includes leap seconds
Pre-1972 times will be assumed to be UT/GMT

TDB

Barycentric Dynamical Time; synchronous with TT, except for variations in earth’s orbital motion

In most cases where TDB is specified, TEB is really the one used

TEB

Barycentric Ephemeris Time; independent variable in solar system ephemeris, linear function of TT

Requires specification of the solar system and planetary ephemeris 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.5.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.5.1.4 Planetary ephemeris (if needed)

The planetary ephemeris object PlanetaryEphem indicates which solar system ephemeris was used in the AstroCoordSys. In general, this will be JPL’s DE200 or DE405 (default). 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 Almanac7 may be considered a known authoritative source for the purpose of spatial reference frames. If the SpaceRefFrame (see: Section 4.5.2.3) is defined on a body, ephemeris information on its coordinate system (pole, primary meridian) must be included in the PlanetaryEphem.

In the XML implementations this element is nillable.

 

4.5.2 SpaceFrame

The Space Frame contains a reference position, a reference frame, and a coordinate flavor object.

 

4.5.2.1 ReferencePosition

This object is of the same class as described in Section 4.5.1.1, with the following restrictions. The value RELOCATABLE is allowed, but LSRD, LSRK, GALACTIC_CENTER, and LOCAL_GROUP_CENTER are not. Obviously, if an explicit coordinate origin is provided, those coordinates should be referenced to a different CoordSys; one may still nest them, but eventually they should be referenced to a known standard origin.

 

4.5.2.2 CoordFlavor

This class is peculiar to spatial coordinates. It indicates the intrinsic dimensionality of the coordinate system (1, 2, or 3), and the type of coordinates: Cartesian, spherical, unitsphere, or POLAR. For 3-dimensional SPHERICAL (because of geographical applications) we allow the special Units value “deg deg m”. The UnitSphere has default units “”. This list will likely be expanded with, for instance, cylindrical coordinates.

 

4.5.2.3 SpaceRefFrame

While the Reference Position pins down the origin of the spatial coordinate system, the Space Reference Frame specifies its orientation. In most cases this will be a StdFrame, consisting of a RefSystem (FK4, FK5, ECLIPTIC, ICRS, GALACTIC_I, GALACTIC_II, SUPER_GALACTIC, AZ_EL, BODY; the first three require a CoordEquinox, which is nillable in the XML implementation). The Standard Frame may be BODY if the Reference Position is specified as a solar system object. In addition, we allow solar, lunar, planetary, and planetary satellite coordinate frames (planetocentric and planetographic) as defined by Sections 7.2-7.5 of the Explanatory Supplement to the Astronomical Almanac (Seidelmann, 1992)[7]; see also Fränz & Harper (2002)[8]. For the most current update of cartographic coordinates and rotation rates, see Seidelmann et al. (2002)[9].

A full list of Standard Reference Frames is provided in Table 3.

Alternatively, a CustomFrame may be specified by way of the pole (Z) axis and the longitude zero-point (X-axis) directions.

 

We want to provide some caveats on subtle differences between various coordinate systems that may look similar.

First, one should note that the 2-dimensional spherical versions of all celestial coordinate systems are left-handed, but that their 3-dimensional Cartesian versions are right-handed.

Second, because of the definition of longitude (IAU 1970), following astronomical tradition, longitude increases westward in the planetographic coordinate frames for Mercury, Mars, Jupiter, Saturn, and Neptune (MERCURY_G, MARS_G, JUPITER_G, SATURN_G, and NEPTUNE_G – ignoring planetary satellites), since their rotation is direct (prograde); hence, these coordinate systems are also left-handed. Note that earth, sun, and moon are exempted from this rule because of even older conventions. In addition, many coordinate systems that are based on video devices are left-handed. All other coordinate systems (including all planetocentric systems) are right-handed.

Finally, beware that planetographic and planetocentric coordinates may differ in three respects:

For further details, see Seidelmann (1992, Sections 4.2 and 7)7, Seidelmann et al. (2002)9, and Duxbury et al. (2002)[10].

 

 

Table 3. Standard Reference Frames

 

Reference Frame

Description

Comments

FK4

Fundamental Katalog, system 4; Besselian

Requires Equinox; default B1950.0
Left-handed in spherical coordinates

FK5

Fundamental Katalog, system 5; Julian

Requires Equinox; default J2000.0
Left-handed in spherical coordinates

ECLIPTIC

Ecliptic coordinates

Left-handed in spherical coordinates

ICRS

International Celestial Reference System

Left-handed in spherical coordinates

GALACTIC_I

Old Galactic coordinates

Left-handed in spherical coordinates

GALACTIC[_II]

“New” Galactic coordinates

Left-handed in spherical coordinates

SUPER_GALACTIC

Super-galactic coordinates:
pole at GALACTIC_II (47.37,+6.32)
origin at GALACTIC_II (137.37,0)

Left-handed in spherical coordinates

AZ_EL

Local azimuth and elevation

Ground-based observatories
Azimuth: from north through east

BODY

Generic “BODY” coordinates

 

GEO_C

Geographic (geocentric) coordinates: longitude, latitude, geocentric distance

3-D spherical or 3-D Cartesian

GEO_D

Geodetic coordinates: longitude, latitude, elevation

Semi-major axis and inverse flattening of the reference spheroid may need to be provided; default is IAU 1976 (6378140 m, 298.2577)

MAG

Geomagnetic coordinates

 

GSE

Geocentric Solar Ecliptic coordinates

 

GSM

Geocentric Solar Magnetic coordinates

 

SM

Solar Magnetic coordinates

 

HGC

Heliographic coordinates

See Explanatory Supplement, Section 7.2

HEE

Heliocentric Earth Ecliptic coordinates

 

HEEQ

Heliocentric Earth Equatorial coordinates

 

HCI

Heliocentric Inertial coordinates

 

HCD

Heliocentric coordinates of Date

 

MERCURY_C

Planetocentric coordinates on Mercury

See Explanatory Supplement, Section 7.4

VENUS_C

Planetocentric coordinates on Venus

See Explanatory Supplement, Section 7.4

LUNA_C

Selenocentric coordinates

See Explanatory Supplement, Section 7.3

MARS_C

Planetocentric coordinates on Mars

See Explanatory Supplement, Section 7.4

JUPITER_C _III

Planetocentric coordinates on Jupiter, system III

See Explanatory Supplement, Section 7.4

SATURN_C _III

Planetocentric coordinates on Saturn, system III

See Explanatory Supplement, Section 7.4

URANUS_C _III

Planetocentric coordinates on Uranus, system III

See Explanatory Supplement, Section 7.4

NEPTUNE_C _III

Planetocentric coordinates on Neptune, system III

See Explanatory Supplement, Section 7.4

PLUTO_C

Planetocentric coordinates on Pluto

See Explanatory Supplement, Section 7.4

MERCURY_G

Planetographic coordinates on Mercury

See Explanatory Supplement, Section 7.4
Left-handed

VENUS_G

Planetographic coordinates on Venus

See Explanatory Supplement, Section 7.4

LUNA_G

Selenographic coordinates

See Explanatory Supplement, Section 7.3

MARS_G

Planetographic coordinates on Mars

See Explanatory Supplement, Section 7.4
Left-handed

JUPITER_G _III

Planetographic coordinates on Jupiter, system III

See Explanatory Supplement, Section 7.4
Left-handed

SATURN_G _III

Planetographic coordinates on Saturn, system III

See Explanatory Supplement, Section 7.4
Left-handed

URANUS_G _III

Planetographic coordinates on Uranus, system III

See Explanatory Supplement, Section 7.4

NEPTUNE_G _III

Planetographic coordinates on Neptune, system III

See Explanatory Supplement, Section 7.4
Left-handed

PLUTO_G

Planetographic coordinates on Pluto

See Explanatory Supplement, Section 7.4

UNKNOWN

Unknown reference frame

Only to be used as a last resort
The client is responsible for assigning a suitable default

 

 

4.5.2.4 OffsetCenter

In order to accommodate positions that are given as offsets in Right Ascension and Declination from some specific position, the optional OffsetCenter object is provided. Note that this is purely for numeric offsets. True angle offsets should be handled through a CustomFrame.

 

4.5.2.5 Position Angles

Position angle definitions can be a great source of confusion. To reduce ambiguity, we will attach a Reference attribute to position angles that may have the values “North”, “X” (default), or “Y”. If the reference is “North”, position angles will be counted from north through east; this should only be used with coordinate systems where “North” has meaning. If the reference is “X” (the default), the position angle will be counted from the positive first coordinate axis through the positive second coordinate axis. If the reference is “Y”, the position angle will be counted from the positive second coordinate axis through the positive first coordinate axis. These definitions are independent of the handedness of the coordinate system. For spherical systems, the longitude is considered the first axis in this context, and latitude the second. Note that in most (though not all) cases “North” is equivalent to “Y”.

 

4.5.3 SpectralFrame

The Spectral Frame only contains a reference position.

 

4.5.3.1 ReferencePosition

This object is of the same class as described in Section 4.5.1.1, without any restrictions.

 

4.5.4 RedshiftFrame

The Redshift Frame contains two objects: a reference position and a Doppler definition object.

 

4.5.4.1 ReferencePosition

This object is of the same class as described in Section 4.5.1.1, without any restrictions.

 

4.5.4.2 DopplerDefinition

This object specifies what the definition of redshift is and how it should be translated to Doppler velocity. Allowed values are OPTICAL, RADIO, and RELATIVISTIC.

OPTICAL:                        

RADIO:                             

RELATIVISTIC:            

It should be emphasized that Doppler velocities are formal velocities; i.e., defined by a formalism and not necessarily physical in nature. One should also note here that RELATIVISTIC is not strictly correct and we should, at some point, probably move toward compliance with the third FITS WCS paper.

An attribute indicates what the type of the values is, VELOCITY or REDSHIFT. We strongly advise against using REDSHIFT with anything but OPTICAL.

In the XML implementations this element is nillable.

 

4.6 AstroCoords

The AstroCoords object specifies a particular position in STC coordinate space. It requires a reference to an AstroCoordSys object and it is made up of 1 to 5 Coordinate objects, at most one each of the following:

Note that all objects are optional. However, in order to constitute a meaningful AstroCoords object, one would expect at least one of them to be present.

The three specialized STC Coordinate classes, TimeCoord, SpatialCoord, and SpectralCoord, are all derived from a generic base-class Coordinate (see: Section 4.3.1). Instead of providing the actual coordinate elements, the object may refer to a FITS file that provides some or all of them.

Also note that if both a Redshift coordinate and a Spectral coordinate are present, the latter will contain rest frequency values.

 

4.6.1 TimeCoord

The error, resolution, size, and pixel size components of this class (derived from Coordinate) are fully generic, i.e., consisting of a scalar value (double) and unit string. The allowed time units are ‘s’ (second), ‘d’ (day = 86400 s), ‘yr’ or ‘a’ (Julian year = 365.25 d), ‘cy’ (Julian century = 36525 d).

The CoordValue object in TimeCoord is of class AstronTime.

 

4.6.1.1 AstronTime

A time (i.e., a particular instant in history) is an aggregate of two or three objects: a TimeScale (Section 4.5.1.2), an AbsoluteTime, and, optionally, a RelativeTime (or ElapsedTime). Note that, in principle, all times are really elapsed times. The difference is that for absolute times there is an implicit agreement as to what the reference instant in time is.

 

4.6.1.1.1 AbsoluteTime

AbsoluteTime contains is instantiated as one of its four subclasses:

  1. ISOTime: a time instant expressed in a subset of the ISO-8601 format; i.e., a string of format yyyy-mm-ddThh:mm:ss.sss…; the integer part of the seconds is in the range 0 to 60 for time scales that include leap seconds, 0 to 59 for all other time scales. We shall assume that ISOTime always relates to an (extrapolated) Gregorian date, independent of date and place, though caution should be exercised when using it for dates before, say, 1800 CE (some might argue 1918 CE). The earliest date that can be expressed in this format is 0001-01-01; prior to this date one should use JDTime.

2.      JDTime: a decimal number (note: in principle unlimited precision!) representing the Julian Day of a particular instant.

3.      MJDTime: a decimal number (note: in principle unlimited precision!) representing the Modified Julian Day of a particular instant (MJDTime = JDTime – 2,400,000.5).

4.      TimeOrigin: a string with the value RELOCATABLE, primarily for simulation work, to be used in conjunction with TimeScale LOCAL and a RELOCATABLE SpaceFrame.

 

4.6.1.1.2 RelativeTime

Relative time is a decimal number representing the amount of time elapsed since AbsoluteTime. It includes a unit.

 

4.6.2 SpatialCoord

Spatial coordinates are special in that they can be explicitly multi-dimensional and that they serve positions as well as their first time derivatives (physical velocities – not to be confused with redshifts or Doppler velocities). Not only does this mean that scalar values are to be replaced by vectors, but components like errors, resolutions, and sizes become more complicated. SpatialCoord is an aggregate of CoordName, Dimensionality, CoordValue (class SCValue), CoordError, CoordResolution, CoordSize, CoordPixSize (all class MultiCoord). We stress that Dimensionality should force all components of SpatialCoord to be consistent in type and content.

It may well be that there is merit in sub-classing a VelocityCoord class, since sexagesimal formats are not needed and a time unit needs to be added. Either way, we suggest that the units for velocity be the same as for position, but that a (standard) time unit be added for the denominator.

 

4.6.2.1 Dimensionality

A single object of this class controls all components of the SpatialCoord class by specifying how many coordinate axes need to be represented. Note that this is distinct from the CoordFlavor object described in Section 4.5.2.2: CoordFlavor specifies the number of spatial axes defined in the AstroCoordSys; Dimensionality specifies how many of those are actually provided in the AstroCoords object – one could envision a catalog with only Right Ascensions, where the CoordFlavor would be spherical, 2-dimensional, but the dimensionality just be 1.

 

4.6.2.2 CoordName

This object now contains a list of <Dimensionality> strings with the names of all axes present.

 

4.6.2.3 SCValue

The spatial coordinate value is a vector (length determined by Dimensionality) of numbers (SValue).

 

4.6.2.4 MultiCoord

Expressing errors and sizes for vectors is slightly more complicated. If the errors are independent for each vector component, then a simply SValue object (vector of decimal values with a Unit) will do. If they are not independent (or if the resolution is tilted), one can either add a PosAngle (see also Section 4.5.2.5) to the SValue object, or specify the MultiCoord object through a Matrix of decimal values with a Unit. Position angles are measured following the definition in Section 4.5.2.5.

 

4.6.3 SpectralCoord

The SpectralCoord is used for the spectral as well as the redshift components of the AstroCoords object. It is a completely generic Coordinate class (see: Section 4.3.1) where Name is a string and all other components consist of a double Value and a string Unit.

 

4.7 AstroCoordArea

The Coordinate Area class defines the volume in coordinate space that is occupied by (or: the coverage of):

It is an aggregate of one or more ranges in individual coordinates and is required to have a reference to an AstroCoordSys. Multiple ranges along each coordinate axis are OR-ed together; the ranges of different axes are logically AND-ed together.

 

4.7.1 TimeInterval

A TimeInterval consists of a StartTime and/or a StopTime, both of which are instantiations of AstronTime. Note that they do not both have to be present, but at least one of them needs to be. TimeInterval has Boolean attributes LoLimInclude and HiLimInclude, and attribute FillFactor (see Section 4.4.1).

 

4.7.2 SpatialInterval

The spatial position area has more options:

 

4.7.2.1 CInterval

CInterval is the vector equivalent of ScalarInterval (see: Section 4.4.1). LoLimit and HiLimit are of type SCValue (see Section 4.6.2.3).

 

4.7.2.2 Sphere

Since spherical regions are quite common (cone search!) these are made available as special cases. The class is an aggregate of a Center position (of type CValue; see: Section 4.6.3.3) and a Radius (consisting of a double and a unit). The spatial coordinates of the center should be in the AstroCoordSys associated with AstroCoordArea, of course. Note that the 2-D equivalent (circle) is available in the Region class (see: Section 4.8).

 

4.7.2.3 SpatialRegion

This is an object of class Region (see: Section 4.8).

 

4.7.3 VelocityInterval

The velocity interval is an instantiation of CInterval (see: Section 4.7.2.1).

 

4.7.4 SpectralInterval

The SpectralInterval is derived from the generic ScalarInterval class (see: Section 4.4.1), restricting Unit to appropriate values.

 

4.7.5 RedshiftInterval

The RedshiftInterval is derived from the generic ScalarInterval class (see: Section 4.4.1), restricting Unit to appropriate values.

 

4.8 Region

The Region specification is a rather elaborate construct that allows a very flexible definition of arbitrary 2-dimensional spatial shapes. It has 9 derived classes: 5 shapes and 3 operations. Note that the result of these operations performed on one or more regions is a region. All spatial coordinates should be in the AstroCoordSys associated with AstroCoordArea (or Region), of course. The Region object has an important attribute, fill_factor (between 0.0 and 1.0; default 1.0) that indicates what fraction of the region is really filled or covered. This is particularly useful when describing a resource’s coverage.

 

4.8.1 Shapes

The first four shapes are 2-dimensional, while the remaining two are 3-dimensional, associated with the unit sphere. All boundaries are considered part of the inside of a shape. Different shapes in the same Re