(r27) STC2 < IVOA

IVOA Web>IvoaDataModel>STC>STC2 (revision 27) (raw view)~~EditAttach~~
---+ STC version 2.0

%TOC{depth="3"}%
---++ 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

editor(s): MarkCresitelloDittmar

<span style="background-color: transparent;">author(s)</span>

   * <span style="background-color: transparent;">Coords: </span>ArnoldRots<span style="background-color: transparent;">, </span>GerardLemson<span style="background-color: transparent;">, </span>OmarLaurino
   * <span style="background-color: transparent;">Trans: </span>ArnoldRots<span style="background-color: transparent;">, </span>DavidBerry<span style="background-color: transparent;">, </span>StevenCrawford<span style="background-color: transparent;">, </span>NadiaDencheva<span style="background-color: transparent;">, </span>PerryGreenfield<span style="background-color: transparent;">, </span>TimJenness<span style="background-color: transparent;">, </span>OmarLaurino<span style="background-color: transparent;">, </span>StuartMumford<span style="background-color: transparent;">, </span>ErikTollerud
   * <span style="background-color: transparent;">Meas: </span>ArnoldRots<span style="background-color: transparent;">, </span>GerardLemson<span style="background-color: transparent;">, </span>OmarLaurino
contributor(s):

Many thanks to those who contributed to the quality of the models through review and assessments. In particular,

   * MarkusDemleitner - thorough reviews with attention to usability and impact on users/clients of various representations
   * AdaNebot - review and assessment in the context of TimeSeries data
   * FrancoisBonnarel - review and detailed assessments of Transform model

---++ Uses cases

1) The primary use case for this work is in support of the CubesDM
   * focus on N-Dimensional model pixelated image and sparse data cubes;
   * General 
      * knowledge of the pixel and physical domain spaces provided at a high level
      * definition of the domain space includes the following criteria 
         * dimensionality (typically 1,2 or 3 for physical domain), pixel domain may be of any dimension
         * axis configuration (for spatial domain which has &gt;1D). The most common configurations for astronomical data are Cartesian and Spherical, but others may be used as well.
         * domain range along each axis, typically +/- Inf, but may be limited due to physical constraints (e.g. physical size of a detector, sensitivity limitiations, etc)
         * association with additional metadata further describing the nature of the domain space ( Frame ). This is especially true for the Spatial and Temporal domains, but may apply to others as well. 
            * reference position (location of origin)
            * reference frame (orientation of the domain space)
            * planetary ephemeris
            * equinox
   * Pixelated Image Cube 
      * complete specification of pixel coordinate domain; number of axes, number of pixels per axis
      * image axes 
         * in pixel domain, are a binned coordinate space with integerized values (pixel indexes)
         * mapped to various 'physical' coordinate spaces via transform operations 
            * any combination of pixel axes may be involved in transform to any given 'physical' space
            * any pixel axis may be involved in more than one mapping
            * mappings often involve multiple steps executed in sequence
            * mappings may define a progressive migration in coordinate space (e.g. pixel -&gt; ccd -&gt; detector -&gt; sky -&gt; wcs ) 
               * intermediate stages may or may not be explicitly defined. Therefore, mappings must be stackable in series.
            * transform operations should be flexible in covering the n-dimensional space. e.g. Application of Scale operations to 1D, 2D, nD axes.
            * pixel axis mappings are typically to a continuous domain, but may also be to a discrete domain such as Polarization state.
      * image cubes may have any number of dimensions, but are typically separable into co-dependent axes of 1, 2, or 3 dimensions. 
         * spatial domain typically 2-3 dimensions
         * other domains (time, spectral, polarization), are typically 1 dimensional
      * image data value is typically given in a physical domain, but may itself be mapped to other domains
   * Sparse Cube 
      * data axes cover a wide array of physical domains including, but not limited to Spatial, Temporal, Spectral, Polarization,
      * individual domains may be represented multiple times in different frames ( ccd, detector, sky; pha, energy )
      * data values may have associated errors 
         * typical error forms include: symmetric( +/- a ), asymmetric( +a:-b ), interval ( a:b ), matrix
         * for multi-dimensional: elliptical,
         * quality indicators: 
            * global status, typically numeric
            * bit array, where each bit is associated with a particular quality state
         * for multi-dimensional data, associated errors may be separable or correlated
      * data axes may be virtual, defined as a mapping from other data axes 
         * here, the originating space is not pixelated, but an arbitrary space.
         * axes involved in a mapping need not be associated with the same physical domain. 
            * X,Y = Map(x,y,temp); Transform with spatial and thermal dependence
         * dimensionality may change between operations
   * Physical Data (Observables) 
      * focus the following domains which are frequently included in astronomical data cubes. Domains: Spatial, Spectral, Temporal, Polarization.
      * Spatial 
         * Cartesian space: chip, detector, sky
         * Spherical space: Equatorial, Ecliptic, Galactic, LongLat
      * Time 
         * 1Dimensional: JD, MJD, ISOTime, TimeOffset
      * Polarization 
         * Discrete space: Polarization states (Stokes, Linear, Circular, Vector )
      * Spectral 
         * 1Dimensional: energy, frequency, wavelength
2) An implementation project focused on the Transform model to be undertaken by members of LSST and STSci community to evaluate the usability and applicability of the model to their missions. The focus of this project is to exercise the Transform model through a workflow consisting of:
   * serialization in YAML of complete WCS metadata, including source/target frames and the various Transform operation sequences between them.
   * the generation and passing thereof between two Transform library implementations 
      * <a target="_blank" href="http://starlink.eao.hawaii.edu/starlink/AST" title="AST">AST</a>
      * <a target="_blank" href="https://gwcs.readthedocs.io/en/latest/" title="GWCS">GWCS</a>
   * This use case emphasizes the workflow and combination of atomic operations. 
      * combining operations in parallel to cover the dimension space
      * combining operations in series to accomplish multi-stage mappings
      * management and direction of axes through the operation sequence, for example: 
         * duplicate axes x and y to send pair into 2D-Polynomial transforms, generating x',y'; in reverse direction, select axes 3 and 2
         * from 4D axis set, send axes 1,3 into operation A, axis 2 into operation B, axis 4 into operation C
         * send 2D axis set into 3D operation, adding axis 3 with default value.
      * handling of both forward and inverse operations 
         * for operations with no natural inverse, must be able to assign (optionally) an independent operation spec to be used in that direction.

---++ Requirements

<br />Examination and implementation of the above cases leads to the following set of requirements distributed through the various STC component models.
   * Structure 
      * [vodml.001] The model shall be vo-dml compliant, producing a validated vo-dml XML description.
      * [vodml.002] shall re-use, or refer to, dependent models for objects and concepts already defined in other models
      * [vodml.003] shall produce documentation in vo-dml HTML format
      * [vodml.004] shall produce documentation in standard PDF format
   * Application/Usage 
      * [user.001] 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.
      * [user.002] When applicable, the model should support usability by simplifying common scenarios. 
         * i.e. keep common things simple, and complex things possible
   * Domains 
      * [dom.001] Shall accommodate the description of data in any observable domain
      * [dom.002] Shall provide enhanced/specialized description for data pertaining to * [dom.0002.1] Pixel domain: binned, integerized, n-dimensional domain * [dom.0002.2] Spatial domain: continuous domain, typically in 2-3 dimensional cartesian or spherical spaces * [dom.002.3] Time domain: continuous 1D domain, typically provided in JD, MJD, ISO, or as an Offset from a zero point * [dom.0002.4] Polarization domain: discrete 1D domain of polarization states.
   * Measurements 
      * [meas.001] Shall relate a coordinate value with associated errors
      * [meas.002] Shall support multiple error associations per value to describe errors from different sources
      * [meas.003] Any specific error source may appear only once
      * [meas.004] Errors may be correlated between component values ( ie: may apply to coordinate set as a whole )
      * [meas.005] Values associated with different domains may have correlated errors (ie: components of coordinate tuple may refer to different domains, and have non-separable errors)
      * [meas.006] Shall support the most common error forms, including, but not limited to: Symmetrical, Asymmetrical, Interval, Elliptical, Matrix
      * [meas.007] Shall provide specialized objects related to measurements in the priority domains ( Spatial, Spectral, Temporal, Polarization ); leveraging [user.0002] where possible
      * [meas.008] Shall allow for the representation data outside the priority domains
   * Coordinates 
      * Coordinate Spaces: 
         * [coords.001] Shall facilitate the description of the domain space 
            * [coords.001.1] Coordinate space shall consist of 1 to N dimensional axes
            * [coords.001.2] Shall support the description of axes which are continuous, binned, and discrete in nature
            * [coords.001.3] Each dimensional axis shall define the domain range of that axis as appropriate for its nature
      * Coordinate frames: 
         * [coords.002] Shall facilitate the specification of the nature of the domain, providing additional metadata relevant to the interpretation of coordinates in that domain.
      * Coordinates: 
         * [coords.003] Shall identify a location within the coordinate domain space
         * [coords.004] Shall be associated with a corresponding coordinate frame providing metadata relevant to the interpretation of the coordinate
         * [coords.005] Shall be associated with a particular axis of the coordinate space to provide context for the coordinate and facilitate the application of mapping Transforms
         * [coords.006] Shall be complete quantities, including value and units as appropriate
         * [coords.007] Shall support the association of atomic coordinates into a multi-dimensional compound grouping
      * Coordinate systems: 
         * [coords.008] Shall provide for encapsulating the description of the entire domain space
         * [coords.009] for Pixel domain, this must include the full coordinate space description
         * [coords.010] for Physical domains, this must include the Frame specifications, as it is this metadata that is more relevant to users. The coordinate space is typically well defined or implied by the coordinate itself.
   * Transforms: 
      * [trans.001] Shall facilitate the relation of two coordinate frames through a mathematical formula (Transforms) 
         * [trans.001.1] Shall facilitate the transport of same independent of any actual data
      * [trans.002] Shall define a set of atomic Transform operations commonly used in astronomical applications 
         * [trans.002.1] at a minimum, will accomodate common operations found in FITS images and data cubes, including but not limited to: 
            * Linear, Matrix, FITS WCS projection, Lookup table, Polynomial (1D and 2D)
         * [trans.002.2] shall accommodate and be compatible with established implementation packages AST, and gWCS
      * [trans.003] Shall allow the combination of operations in sequence, to form complex, multi-stage transforms.
      * [trans.004] Shall allow the combination of operations in parallel to cover the appropriate domain space
      * [trans.005] Shall support bi-directional workflow (forward and inverse), including the explicit assignment of independent operations for types which have no natural inverse.
      * [trans.006] Shall provide operations to facilitate a work flow that requires manipulation of the dimensional axes through the process 
         * [trans.006.1] duplicate axes, e.g. to send axis pair (x,y) into 2 Poly2D operations to form (x',y')
         * [trans.006.2] shuffle axis order [x,y,z] =&gt; [x,z,y]
         * [trans.006.3] add or drop dimensions
         * [trans.006.4] allow explicit control of flow in both forward and inverse directions 
            * [trans.006.4.1] preferential selection of source in reverse direction for duplicated input axes
            * [trans.006.4.2] one-to-one axis mappings are not, necessarily, bi-directional

---++ Documents

*Latest Document:*

The most current documentation may be found on Volute:

*Volute:*

The current drafts of the document, including all images and source document can be found in the volute repository.. [[https://volute.g-vo.org/svn/trunk/projects/dm/STC/doc][here]]

*UML Model:*

We also provide an export of the [[https://volute.g-vo.org/svn/trunk/projects/dm/STC/model][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 [[https://volute.g-vo.org/svn/trunk/projects/dm/STC/vo-dml][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.
   * [[http://mail.ivoa.net/pipermail/dm/2015-December/005271.html][initial discussion in Cube thread]]
   * [[http://mail.ivoa.net/pipermail/dm/2015-November/005268.html][STC2 Model and VO-DML Issues]] - spawn to independent thread
   * [[http://mail.ivoa.net/pipermail/dm/2015-December/005290.html][STC2 Model and VO-DML Issues]] - pickup Dec. entries
Cube dependencies
   * [[http://mail.ivoa.net/pipermail/dm/2017-February/005462.html][cube relation to STC ]]
   * [[http://mail.ivoa.net/pipermail/dm/2017-February/005463.html][Time Series Cube DM]]
   * [[http://mail.ivoa.net/pipermail/dm/2017-March/005475.html][Time Series Cube DM ,Continued]]
<span style="background-color: transparent;">Working Draft Review:</span>
   * 2017-05-15 version: 
      * <span style="background-color: transparent;">[[http://mail.ivoa.net/pipermail/dm/2017-May/005561.html][<span style="background-color: transparent;">STC2 docs</span><span style="background-color: transparent;">]]</span></span>
   * Coords: 
      * 2019-03-20 version: 
         * [[http://mail.ivoa.net/pipermail/dm/2019-April/005820.html][Vocabulary Lists]]
         * [[http://mail.ivoa.net/pipermail/dm/2019-June/005839.html][Request for additional clarification between Coords and Meas model usage]]
         * [[http://mail.ivoa.net/pipermail/dm/2019-July/005881.html][Correction to Vocabulary URLs in document ]]
      * <span style="background-color: transparent;">2018-11-30 version:</span> 
         * <span style="color: #7a4707; font-family: ">[[http://mail.ivoa.net/pipermail/dm/2018-December/005761.html][Coordinates model - Working draft]]</span>
         * <span style="color: #7a4707; font-family: ">[[http://mail.ivoa.net/pipermail/dm/2019-January/005785.html][Continues - Jan 2019]]</span>
<span style="color: #7a4707; font-family: "> </span>
   * Trans: 
      * [[http://mail.ivoa.net/pipermail/dm/2018-November/005730.html][STC transforms/Polynomial distortions]] - evaluation presentation of Transform model content.
   * Meas: 
      * 2019-05-01 version: 
         * [[http://mail.ivoa.net/pipermail/dm/2019-June/005839.html][Request for additional clarification between Coords and Meas model usage]]
         * [[http://mail.ivoa.net/pipermail/dm/2019-August/005929.html][Exploratory questions regarding discrete types of Measurement]]
RFC Review:

   * RFC comments can be found at
      * Coordinates model [[https://wiki.ivoa.net/twiki/bin/view/IVOA/CoordsRFC][RFC page]]
      * Measurement model [[https://wiki.ivoa.net/twiki/bin/view/IVOA/MeasRFC][RFC page]]
   * RFC comment summary and action list was posted to the [[http://mail.ivoa.net/pipermail/dm/2020-February/005975.html][DM working group mail list.]]
---++ 
---++ Implementations

*Serializations:*
   * VOTable COOSYS 
      * this represents a standardized serialization of a Coordinate model SpaceFrame 
         * COOSYS =&gt; SpaceFrame
         * COOSYS.system =&gt; SpaceFrame.spaceRefFrame
         * COOSYS.equinox =&gt; SpaceFrame.equinox
         * COOSYS.epoch =&gt; would map to epoch of a particular measurement set, outside the scope of SpaceFrame
         * NOTE: COOSYS lacks the 'refPosition' present in SpaceFrame.. this is on the list as a probable enhancement to COOSYS
   * VOTable TIMESYS 
      * in progress for VOTable 1.4, this is similarly, a standardized serialization of Coordinate model TimeFrame 
         * TIMESYS =&gt; TimeFrame
         * TIMESYS.timescale =&gt; TimeFrame.timescale
         * TIMESYS.refPosition =&gt; TimeFrame.refPosition
         * TIMESYS.timeorigin =&gt; TimeOffset.time0; centralizing this information high in the serialization
   * Externally generated 
      * jovial: A set of example serializations of various Coordinate and Measurement instances generated by Omar Laurino using his Jovial DSL package 
         * <a target="_blank" href="https://olaurino.gitlab.io/ivoa-dm-examples/0000/01/03/Coords.html">https://olaurino.gitlab.io/ivoa-dm-examples/0000/01/03/Coords.html</a>
         * https://olaurino.gitlab.io/ivoa-dm-examples/0000/01/02/STC-current.html - examples of Measurement and Coords based on earlier versions of the models
      * vodml Parser: Notebook developed by Omar Laurino parses vo-dml/Mapping annotation to generate instances of TimeSeries-Cube-Meas-Coord using AstroPy and generates plots of the content using Matplotlib. Note: this was developed and presented in 2017 using earlier drafts of the models. These vary only in detail, and the demo could be updated to the current model suite. 
         * https://olaurino.gitlab.io/ivoa-dm-examples/0000/01/10/PythonParserDemo.html
      * TDIG: Working project of Time Series as Cube. 
         * Example serializations have been generated using various annotation syntax to identify the model elements.
   * Modeler Examples: 
      * using home grown python code, the modeler has generated example serializations which span all elements of the models. The examples are generated in 3 formats: 
         * VOTable-1.3 standard syntax; Validates using votlint
         * VOTable-1.3 annotated with VO-DML/Mapping syntax; Validates using xmllint to a VOTable-1.3 schema enhanced with an imported VO-DML mapping syntax schema
         * XML format; Validates against the model schema
         * An internal DOC format; XML/DOM structure representing the instances generated when interpreting the templates.
*Tools:*
   * TDIG: Working project of Time Series as Cube. 
      * An ongoing project is underway to enhance SPLAT to load/interpret/analyze TimeSeries data, the tool being enhanced to use new annotations (eg: TIMESYS) to identify and interpret the data automatically.
      * Delays in resolving on a standard annotation syntax has delayed progress on this project to fully realize the possibilities. This is a high-priority for upcoming work.
   * pyVO: extract_skycoord_from_votable() 
      * Demonstrated in Paris this product of the hack-a-thon generates AstroPy SkyCoord instances from VOTables using various elements embedded in the VOTable. 
         * Interrogates a VOTable, identifies key information and uses that to automatically generate instances of SkyCoord. 
            * UCD: 'pos.eq.ra', 'pos.eq.dec'
            * COOSYS.system: "ICRS", "FK4", "FK5"
            * COOSYS.equinox
         * The COOSYS maps directly to SpaceFrame, and the value of the system
         * The UCD 'pos.eq' maps directly to meas:EquatorialPosition; with 'pos.eq.ra|dec' identifying the corresponding attributes (EquatorialPosition.ra|dec) as coordinates coords:Longitude and coords:Latitude.
         * This illustrates that even with minimal annotation, this sort of automatic discovery/instantiation can take place. With a defined annotation syntax, this utility could be expanded to generate other AstroPy objects very easily.
*Libraries:*

The Transform model is compatible with three popular and well establised Transform implementation libraries. The table below shows the coverage of the various libraries to the model elements:
   * [[http://starlink.eao.hawaii.edu/starlink/AST][AST]]: Starlink's Library for Handling World Coordinate Systems in Astronomy. (Python, Perl, Java, and C )
   * [[https://gwcs.readthedocs.io/en/latest/][GWCS]]: Generalized WCS implementation, with basis in the astropy [[https://docs.astropy.org/en/stable/modeling/][modeling]] package. (Python)
   * [[http://www.atnf.csiro.au/people/mcalabre/WCS/wcslib/][WCSLIB]]: implements the "World Coordinate System" (WCS) standard in FITS (C, Fortran)
| *WCS Transform Model Element* | *AST* | *GWCS* | *WCSLIB* ||
| TransformSet | FrameSet | WCS.pipeline | ||
| TransNode | | WCS.step | ||
| Mapping | Mapping | Model | ||
| CompoundMap | CmpMap | CompoundModel | ||
| ComposeMap | CmpMap | Model composition | | |
| ConcatenateMap | CmpMap | Model concatenation | ||
| BiDirectionalMap | TranMap | Model | ||
| BiDirectionalMap.forwardMap | TranMap.map1 | wcs.forward_transform | ||
| BiDirectionalMap.inverseMap | TranMap.map2 | wcs.backward_transform | ||
| Permute | PermMap | Mapping | ||
| | | | ||
| Unit | UnitMap | Identity | ||
| Shift | ShiftMap | Shift | lin.h ||
| Scale | ZoomMap | Scale | lin.h ||
| Rotate2D | | Rotation2D | ||
| EulerRotation | | EulerAngleRotation | ||
| Matrix | MatrixMap | | ||
| Projection | | | ||
| o SkyProjection | WCSMap | Projection - each alg a separate class | prj.h ||
| o SphericalRotation | | RotateNative2Celestial,RotateCelestial2Native | sph.h ||
| o SpectralProjection | SpecMap | | spx.h ||
| Polynomial1D | PolyMap | Polynomial1D | ||
| Polynomial2D | PolyMap | Polynomial2D | ||
| Lookup | LutMap | Tabular1D,Tabular2D | tab.h ||

---++ Notes

Modifying content added by: -- IVOA.ArnoldRots - 2017-11-07<br /><br />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.
<table cellpadding="2" border="1"> <tbody> <tr> <td> *Property* </td> <td> *Measure* </td> <td> *Coordinate* </td> <td> *Frame* </td> <td> *Description* </td> <td> *Notes* </td> </tr> <tr> <td>Time</td> <td>Time</td> <td>JD</td> <td>TimeFrame</td> <td>Time as a Julian Date</td> <td><br /></td> </tr> <tr> <td><br /></td> <td></td> <td>MJD</td> <td>TimeFrame</td> <td>Time as a Modified Julian Date</td> <td><br /></td> </tr> <tr> <td><br /></td> <td></td> <td>ISOTime</td> <td>TimeFrame</td> <td>Time as a structured string</td> <td><br /></td> </tr> <tr> <td><br /></td> <td></td> <td>TimeOffset</td> <td>TimeFrame</td> <td>Time as an offset from a zero point</td> <td><br /></td> </tr> <tr> <td><br /></td> <td></td> <td><br /></td> <td><br /></td> <td><br /></td> <td><br /></td> </tr> <tr> <td>(ra,dec)</td> <td>EquatorialPosition</td> <td>Longitude</td> <td>SpaceFrame</td> <td>Right Ascension</td> <td rowspan="2">Coordinate in a spherical space with an equatorial reference frame</td> </tr> <tr> <td><br /></td> <td></td> <td>Latitude</td> <td>SpaceFrame</td> <td>Declination</td> </tr> <tr> <td>(l,b)</td> <td>GalacticPosition</td> <td>Longitude</td> <td>SpaceFrame</td> <td>Galactic longitude</td> <td rowspan="2">Coordinate in a spherical space with a galactic reference frame</td> </tr> <tr> <td> </td> <td></td> <td>Latitude</td> <td>SpaceFrame</td> <td>Galactic latitude</td> </tr> <tr> <td>(elong,elat)</td> <td>EclipticPosition</td> <td>Longitude</td> <td>SpaceFrame</td> <td>Ecliptic longitude</td> <td rowspan="2">Coordinate in a spherical space with a ecliptic reference frame</td> </tr> <tr> <td> </td> <td></td> <td>Latitude</td> <td>SpaceFrame</td> <td>Ecliptic latitude</td> </tr> <tr> <td>(long,lat)</td> <td>Position2D</td> <td>Longitude</td> <td>SpaceFrame</td> <td>Longitude</td> <td rowspan="3">

Coordinate in a spherical space; any spherical reference frame other than those listed above
</td> </tr> <tr> <td> </td> <td></td> <td>Latitude</td> <td>SpaceFrame</td> <td>Latitude</td> </tr> <tr> <td>r</td> <td>Position1D</td> <td>R</td> <td>SpaceFrame</td> <td>Radius</td> </tr> <tr> <td>(x,y,z)</td> <td>CartesianPosition</td> <td>X</td> <td>SpaceFrame</td> <td>Cartesian X</td> <td rowspan="3">Coordinate in a cartesian space; may be combined with any reference frame</td> </tr> <tr> <td> </td> <td></td> <td>Y</td> <td>SpaceFrame</td> <td>Cartesian Y</td> </tr> <tr> <td> </td> <td></td> <td>Z</td> <td>SpaceFrame</td> <td>Cartesian Z</td> </tr> <tr> <td><br /></td> <td></td> <td><br /></td> <td><br /></td> <td><br /></td> <td><br /></td> </tr> <tr> <td>Energy</td> <td>GenericMeasure</td> <td>Standard1DCoord</td> <td>none</td> <td>Spectral data expressed as energy</td> <td><br /></td> </tr> <tr> <td>Frequency</td> <td>GenericMeasure</td> <td>Standard1DCoord</td> <td>none</td> <td>Spectral data expressed as frequency</td> <td><br /></td> </tr> <tr> <td>Wavelength</td> <td>GenericMeasure</td> <td>Standard1DCoord</td> <td>none</td> <td>Spectral data expressed as wavelength</td> <td>reqs refraction index?</td> </tr> <tr> <td><br /></td> <td></td> <td><br /></td> <td><br /></td> <td><br /></td> <td><br /></td> </tr> <tr> <td>Polarization</td> <td>Polarization</td> <td>PolStokes</td> <td>none</td> <td>Polarization states - Stokes</td> <td>Discrete axis</td> </tr> <tr> <td><br /></td> <td></td> <td>PolCircular</td> <td>none</td> <td>Polarization states - Circular</td> <td><br /></td> </tr> <tr> <td><br /></td> <td></td> <td>PolLinear</td> <td>none</td> <td>Polarization states - Linear</td> <td><br /></td> </tr> <tr> <td><br /></td> <td></td> <td>PolVector</td> <td>none</td> <td>Polarization states - Vector</td> <td><br /></td> </tr> <tr> <td>(pmra,pmdec)</td> <td>ProperMotion</td> <td>Longitude</td> <td>SpaceFrame</td> <td>Proper motion - Equatorial</td> <td>Coordinate in spherical space with an equatorial reference frame</td> </tr> <tr> <td></td> <td></td> <td>Latitude</td> <td>SpaceFrame</td> <td><br /></td> <td></td> </tr> <tr> <td>(pml,pmb)</td> <td>ProperMotion</td> <td>Longitude</td> <td>SpaceFrame</td> <td>Proper motion - Galactic</td> <td>Coordinate in a spherical space with a galactic reference frame</td> </tr> <tr> <td></td> <td></td> <td>Latitude</td> <td>SpaceFrame</td> <td></td> <td></td> </tr> <tr> <td>(vx,vy,vz)</td> <td>Velocity3D</td> <td>X</td> <td>SpaceFrame</td> <td>Cartesian velocity - X</td> <td>Coordinate in a cartesian space; may be combined with any reference frame</td> </tr> <tr> <td></td> <td></td> <td>Y</td> <td>SpaceFrame</td> <td>Cartesian velocity - Y<br /></td> <td></td> </tr> <tr> <td></td> <td></td> <td>Z</td> <td>SpaceFrame</td> <td>Cartesian velocity - Z<br /></td> <td></td> </tr> </tbody> </table>

---++++ To be migrated
<table align="left" style="height: 508px;" frame="box" rules="all" border="0"> <thead> <tr> <td>

*Attribute*
</td> <td> *Type* </td> <td> *Description* </td> <td> *Constraints* </td> </tr> </thead> <tbody> <tr> <td>pmelong</td> <td>RealQuantity</td> <td>Proper motion in Ecliptic longitude</td> <td rowspan="2">These four attributes may appear together and require a spherical space and an ecliptic reference frame</td> </tr> <tr> <td>pmelat</td> <td>RealQuantity</td> <td>Proper motion in Ecliptic latitude</td> </tr> <tr> <td>pmlong</td> <td>RealQuantity</td> <td>Proper motion in longitude</td> <td rowspan="2">These five attributes may appear together and require a spherical space and any spherical reference frame other than the ones specified above<br /></td> </tr> <tr> <td>pmlat</td> <td>RealQuantity</td> <td>Proper motion in latitude</td> </tr> <tr> <td>dircosx</td> <td>real</td> <td>Direction cosine along X (unit sphere)</td> <td rowspan="7">These three attributes may appear together, require a unit sphere space and may be combined with any reference frame</td> </tr> <tr> <td>dircosy</td> <td>real</td> <td>Direction cosine along Y (unit sphere)</td> </tr> <tr> <td>dircosz</td> <td>real</td> <td>Direction cosine along Z (unit sphere)</td> </tr> <tr> <td>redshift</td> <td><br /></td> <td>'z'</td> </tr> <tr> <td>redshift</td> <td><br /></td> <td>doppler velocity - optical</td> </tr> <tr> <td>redshift</td> <td><br /></td> <td>doppler velocity - radio</td> </tr> <tr> <td>redshift</td> <td><br /></td> <td>doppler velocity - relativistic</td> </tr> </tbody> </table>

---

---+++++ 
---+++++ 
---+++++ 
---+++++ 
---+++++ 
---+++++ 
---+++++ 
---+++++ 
---+++++ 
---+++++ 
---+++++ 
---+++++ 
---+++++ 
---+++++ 
---+++++ 
---
Topic revision: r27 - 2020-06-24 - MarkCresitelloDittmar
IVOA
Log in or Register
IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics
Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki
TWiki intro
TWiki tutorial
User registration
Notify me
Working Groups
Interest Groups
Time Domain
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema