STC version 2.0

Goal

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.

Context and Scope

Measurement: Describes measured or determined data

• associates the coordinate value with errors

Coordinates: Describes the coordinate domain space

• the coordinate space; axes and domain ranges
• coordinate frames with metadata describing the origin and orientation of the coordinate space
• a general model for specifying coordinate values within the coordinate space
• simple specialized coordinates fro the most common cases
• coordinate systems associating related coordinate frames

Transforms: Describes the mechanism to define data as a function of other data. i.e. to transform data from one 'frame' to another

• atomic transform operations
• operations which combine operations into sequences; either in series or in parallel
• operations which facilitate dimensional manipulation
  • add, delete, duplicate dimensions
  • shuffle axis order

Participants

domain experts: Jim Bosch (LSST), Ian Evance (SAO); ArnoldRots (retired)

data modeler: MarkCresitelloDittmar

contributors: MarkCresitelloDittmar (editor), ArnoldRots, GerardLemson, OmarLaurino

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.

2) A implementation project focused on the Transform model. The purpose of which is to exercise the Transform model through a workflow consisting of:

• serialization in YAML of various Transform operation sequences
• the generation and passing thereof between two Transform library implementations
  • AST
  • gWCS

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

---

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.

• initial discussion in Cube thread
• STC2 Model and VO-DML Issues - spawn to independent thread
• STC2 Model and VO-DML Issues - pickup Dec. entries

Implementations

Notes

Modifying content added by: -- ArnoldRots - 2017-11-07

Rather than proposing a set of shortcut elements for the model, we are transforming it to a list of Astronomical properties which should be supported by the model and the current means of representing them.

Property	Coordinate	Frame	Description	Notes
Time	JD	TimeFrame	Time as a Julian Date
	MJD	TimeFrame	Time as a Modified Julian Date
	ISOTime	TimeFrame	Time as a structured string
	TimeOffset	TimeFrame	Time as an offset from a zero point
ra	Longitude	SpaceFrame	Right Ascension	Coordinate in a spherical space with an equatorial reference frame
dec	Latitude	SpaceFrame	Declination
l	Longitude	SpaceFrame	Galactic longitude	Coordinate in a spherical space with a galactic reference frame
b	Latitude	SpaceFrame	Galactic latitude
elong	Longitude	SpaceFrame	Ecliptic longitude	Coordinate in a spherical space with a ecliptic reference frame
elat	Latitude	SpaceFrame	Ecliptic latitude
long	Longitude	SpaceFrame	Longitude	Coordinate in a spherical space; any spherical reference frame other than those listed above
lat	Latitude	SpaceFrame	Latitude
r	R	SpaceFrame	Radius
x	X	SpaceFrame	Cartesian X	Coordinate in a cartesian space; may be combined with any reference frame
y	Y	SpaceFrame	Cartesian Y
z	Z	SpaceFrame	Cartesian Z

To be migrated

Attribute	Type	Description	Constraints
pmra	RealQuantity	Proper motion in RA	These five attributes may appear together and require a spherical space and an equatorial reference frame
pmdec	RealQuantity	Proper motion in Dec
pml	RealQuantity	Proper motion in Galactic longitude	These four attributes may appear together and require a spherical space and a Galactic reference frame
pmb	RealQuantity	Proper motion in Galactic latitude
vx	RealQuantity	Cartesian X velocity	These six attributes may appear together, require a Cartesian space and may be combined with any reference frame
vy	RealQuantity	Cartesian Y velocity
vz	RealQuantity	Cartesian Z velocity
pmelong	RealQuantity	Proper motion in Ecliptic longitude	These four attributes may appear together and require a spherical space and an ecliptic reference frame
pmelat	RealQuantity	Proper motion in Ecliptic latitude
pmlong	RealQuantity	Proper motion in longitude	These five attributes may appear together and require a spherical space and any spherical reference frame other than the ones specified above
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)

---

Spectral Coordinate Value

The general spectral value proxy Data Type is SpectralCoord
It 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.

---