STC version 2.0
Goal
Defines coordinates, coordinate related metadata and their relationships for use in the IVOA data models.
Coordinate: location within the coordinate space.
Coordinate frame: describes the coordinate space for a domain;
Coordinate system: collection of coordinate frames covering the domain space
Why STC-2.0?
Version 1 of
STC was developed in 2007, prior to the development and adoption of vo-dml modeling practices. As we progress to the development of vo-dml compliant component models, it is necessary to revisit those models which define core content. Additionally, the scope of the
STC-1.0 model is very broad, making a complete implementation and development of validators, very difficult. As such it may be prudent to break the content of
STC-1.0 into component models itself, which as a group, cover the scope of the original.
This effort will start from first principles with respect to defining a specific project use-case, from which requirements will be drawn, satisfied by the model, and implemented in the use-case. We will make use of the original model to ensure that the coverage of concepts is complete and that the models will be compatible. However, the form and structure may be quite different. This model will use vo-dml modeling practices, and model elements may be structured differently to more efficiently represent the concepts.
Participants
domain experts:
ArnoldRots
data modeler:
MarkCresitelloDittmar
contributors:
ArnoldRots (editor),
GerardLemson,
OmarLaurino,
MarkCresitelloDittmar
Uses cases
1) The primary use case for this work is in support of the
CubesDM. This will involve the definition of coordinates and associated metadata in several physical domains and pixel domain.
Requirements
- Structure
- The model shall be vo-dml compliant, producing a validated vo-dml XML description.
- shall produce documentation in standard pdf format, and as vo-dml HTML
- shall re-use, or refer to, dependent models.
- Scope
- Requirements of the Cube model incorporate the following concepts/relations within the STC area of discourse
- Coordinate frames; describing domain axes, orientation and origin
- Coordinate systems; collection of coordinate frames providing a complete description of the domain space
- Coordinates; locations within the coodinate space, with association to corresponding domain spec.
- Defining relation between two coordinate frames within the same domain.
- Derived coordinates; measured or calculated values including associated errors
- Requirements of Cube model include the Pixel, Spatial, Temporal, Spectral, and Polarization domains.
- Application/Usage
- Users should be able to identify and use basic content with minimal specialized information.
- in other words, a generic utility should be able to find and use core elements without knowing a lot about the various extensions and uses of those elements.
- Content
- Shall facilitate the specification of the various concepts in all supported domains
- Coordinate frames:
- Shall faciliate the specification of the nature of the domain.
- dimensionality
- origin
- orientation vectors ( for greater than 1D domains )
- May be specified using generally accepted standard definitions
- Must be customizable to facilitate origin relocation
- Coordinate systems:
- Shall provide the Frame specifications for the entire domain space
- Shall NOT require specification in all supported domains
- Any specific domain Shall NOT appear more than once in a single coordinate system specification.
- Coordinates:
- Shall identify a location within the coordinate domain space
- Shall be associated with a corresponding coordinate frame or axis
- Shall be complete value quantities, including value and units as appropriate
- Derived Coordinates:
- Shall relate a coordinate value with associated errors
- Shall support multiple error associations per value to provide errors from different sources
- Any specific error source may appear only once.
- errors may not be separable for greater than 1-D domains ( ie: may apply to coordinate pair or triplet as a whole )
- values associated with different domains may have correlated errors (ie: components of coordinate tuple may refer to different domains, and have non-separable errors)
- Shall facilitate the relation of two coordinate frames through a mathematical formula (Transforms)
- Transforms:
- Must support the following industry standard transform specifications
- FITS WCS
- Linear
- Matrix
- Lookup
Documents
Latest Document:
The current documentation may be found on Volute:
Volute:
The current working draft of the document, including all images and source document can be found in the volute repository..
here
UML Model:
We also provide an export of the
UML specification in XMI format (version 2.4.1), which is compatible with the vo-dml xslt scripts for generating the vo-dml XML representation.
vo-dml:
VO-DML XML serialization of the model and corresponding HTML page are
here
Shortcuts
--
ArnoldRots - 2017-11-07
In order to provide easy access to the model elements, I propose a set of proxy components that through a simplified notation specify define specific model instances. This consistes of an
AstroCoordSystem object and a set of Coordinate Value data types.
AstroCoordSystem's attributes specify a set of instances of the Temporal, Spatial, Spectral, Redshift, and/or Polarization frames. Note that this shortcut proxy only applies to time, space, spectrum, redshift, and polarization; Generic and Pixel coordinate frames need to to specified through the full model. Similarly, only standard frames and reference positions are included. All attributes have multiplicity 0..1. Also note that all frames have to share a common sptial reference position; this will ensure consistency between the domains.
Attribute | Data Type | Description |
spaceRefFrame | StdRefFrame | Spatial reference frame: the orientation of the reference frame in space; only standard reference frames are supported |
refPosition | StdRefPos | Reference position common: the origin for spatial coordinates and the spatial reference position for time, spectral, and redshift coordinates; this may be a state vector |
epoch | Epoch | Optional epoch of spatial coordinate values (e.g., B1950.0, J2000.0, J2017.8345) |
timeScale | TimeScale | Time scale of the TimeStamps (TT, TDT, ET, TAI, IAT, UTC, GPS, TDB, TEB, TCG, TCB, LST) |
planetaryEphem | string | Planetary ephemeris used (if any), especially for spatial and temporal coordinates, but potentially also spectral and redshift coordinate values; default: DE405 |
timeOffset | TimeStamp | Time origin for temporal coordinate values; only required if those values are provided as TimeOffsets |
.
Coordinate Values
There are five shortcut coordinate value data types. These put specific constraints on the
CoordAxis and
CoordSpace objects that they reference in the model. Note that these shortcut proxies only apply to time, space, spectrum, redshift, and polarization; Generic and Pixel coordinates need to to specified through the full model.
Time Coordinate Value
The general time value proxy Data Type is
TimeStampValueIt contains the following attributes (all multiplicity 0..1):
- JD (real)
- MJD (real)
- timeOffset (RealQuantity)
- ISOtime (datetime)
These attributes hold the value of the
cval attribute in the corresponding data types from the model; exactly one needs to be present in each instantiation.
Spectral Coordinate Value
The general spectral value proxy Data Type is
SpectralCoordIt contains the following attributes (all
RealQuantity, mulitplicity 0..1):
- energy
- frequency
- wavelength (additional attribute: refractIndex; default=0.0)
These attributes hold the value of the
cval attribute in the corresponding data types from the model; exactly one needs to be present in each instantiation.
Redshift Coordinate Value
The general redshift value proxy Data Type is Redshift
It contains he following attributes (all
RealQuantity, multiplicity 0..1):
- z or redshift
- dopVelOpt
- dopVelRad
- dopVelRel
These attributes hold the value of the
cval attribute in the corresponding data types from the model; exactly one needs to be present in each instantiation. The three dopvel flavors reflect the value of the
dopplerDefinition attribute.
Polarization Coordinate Value
The general polarization value proxy Data Type is Polarization
It contains the following attributes (all multiplicity 0..1):
- polStokes (PolStokesEnum: I, Q, U, V)
- polCircular (PolCircularEnum: RR, LL, RL, LR)
- polLinear (PolLinearEnum: XX, YY, XY, YX)
- polVector (PolVectorEnum: I, PF, PP, PA)
These attributes hold the value of the
cval attribute in the corresponding data types from the model; exactly one needs to be present in each instantiation.
Spatial Coordinate Value
There is a single Data Type
Position that may contain any of a number of attributes, provided they are consistent with each other. All attributes have multiplicity 0..1.
With the exception of
epoch (which may be present in all instantiations), an instatiation of
Position must contain one or more attributes from one single constraint group.
Attribute | Type | Description | Constraints |
epoch | Epoch | Epoch of the values of the other attributes (overrides SpaceFrame.epoch) | May be combined with all other attributes |
ra | RealQuantity | Right Ascension | These five attributes may appear together and require a spherical space and an equatorial reference frame |
dec | RealQuantity | Declination |
d | RealQuantity | Distance |
pmra | RealQuantity | Proper motion in RA |
pmdec | RealQuantity | Proper motion in Dec |
l | RealQuantity | Galactic longitude | These four attributes may appear together and require a spherical space and a Galactic reference frame |
b | RealQuantity | Galactic latitude |
pml | RealQuantity | Proper motion in Galactic longitude |
pmb | RealQuantity | Proper motion in Galactic latitude |
x | RealQuantity | Cartesian X | These six attributes may appear together, require a Cartesian space and may be combined with any reference frame |
y | RealQuantity | Cartesian Y |
z | RealQuantity | Cartesian Z |
vx | RealQuantity | Cartesian X velocity
|
vy | RealQuantity | Cartesian Y velocity
|
vz | RealQuantity | Cartesian Z velocity
|
elong | RealQuantity | Ecliptic longitude | These four attributes may appear together and require a spherical space and an ecliptic reference frame |
elat | RealQuantity | Ecliptic latitude |
pmelong | RealQuantity | Proper motion in Ecliptic longitude |
pmelat | RealQuantity | Proper motion in Ecliptic latitude |
long | RealQuantity | Longitude
| These five attributes may appear together and require a spherical space and any spherical reference frame other than the ones specified above
|
lat | RealQuantity | Latitude |
r | RealQuantity | Radius |
pmlong | RealQuantity | Proper motion in longitude |
pmlat | RealQuantity | Proper motion in latitude |
dircosx | real | Direction cosine along X (unit sphere) | These three attributes may appear together, require a unit sphere space and may be combined with any reference frame |
dircosy | real | Direction cosine along Y (unit sphere) |
dircosz | real | Direction cosine along Z (unit sphere) |
.
Coordinate Measurement Objects
These classes do not have any specific shortcut proxies. However, the coordinate shortcut proxies defined above may be substituted for the coordinate values in those objects.
Discussion Topics
Significant discussion threads from dm working group mailing list:
STC2 and VO-DML compliance:
Discussion on conflicts between stc2 model and vo-dml rules, specifically regarding the multiplicity of attributes.
Implementations