STC2 Design

[David Berry]

On 5 May 2015 at 17:26, Arnold Rots <arots at cfa.harvard.edu> wrote:
> Dear DMers,
>
> I have been working with Mark Cresitello-Dittmar, Omar Laurino, and
> Gerard Lemson on the STC2 design. It has converged to a reasonable
> degree and may be found at:
>
> https://code.google.com/p/volute/source/browse/#svn%2Ftrunk%2Fprojects%2Fdm%2Fvo-dml%2Fmodels%2FSTC2%2F2015-05-04
>
> The .ump file is not terribly useful, unless you have Altova UModel, but the
> Doc and Diagrams directories will be more helpful.
> Regarding Doc:
> The documentation of the various elements is far from complete, but at least
> there is a start.
>
> The large diagram STC2 shows the elements that are of interest to the user,
> displaying the packages they belong to, and the dependencies between the
> packages. The other diagrams present the individual packages, some basic
> VO-DML packages, and stcTypes - a package of types defined for STC (this
> still
> needs cleaning up - extending enumerations, removing old units).
>
> Color coding
> ------------------
> Packages: pale yellow
> Classes: orange
> DataTypes: yellow
> Enumerations: pink
> Tags (subsetting): gray
> Generalizations: red
> Compositions: blue
> Associations: green
> Package dependencies: magenta
> Note that classes or datatypes copied from their own package into a package
> that needs them are colored by the relation that pulls them in (red or
> green).
>
> The two basic packages are coordSystem and coords.
> The latter clearly has a dependency on the former, but there is also a minor
> dependency in the other direction since we have to allow a non-standard
> reference position in the definition of the coordinate frames. Note that
> this
> does not constitute a circular dependency.
>
> Coordinate Systems contain references to one or more Coordinate Frames.
> Coordinates contain one or more typed coordinates.
> However, neither the Coordinate System, not the container Coordinate are
> required,
> since typed coordinates directly reference corresponding coordinate frames.
>
> A CoordSys consists of 0..* generic coordinate frames and an AstroCoordSys
> is derived from it, optionally containing any of the five astronomical
> coordinate
> frames.
> Temporal, spatial, spectral, redshift coordinate frames need a reference
> position,
> polarization does not.
> Four polarization types are allowed: Stokes, circular, linear, and vector.
>
> A coordinate is still a composite of a value, error (uncertainty), and
> resolution.
> Most of these components are typed as Quantities, meaning they include a
> unit.
> Since there is no mechanism to restrict units (to make sure they are
> appropriate
> for the coordinate value they are attached to), STC2 introduces the SKOS
> concept
> coordinateDomain which narrows the allowable scope as one travels down the
> coordinate tree. The intent is to provide a context-independent mechanism
> that
> controls the scope of the units, rather than having to code those
> restrictions
> separately in each place they are used.
> Spatial coordinates (position and space velocity) are not derived into
> separate
> 1-D, 2-D, and 3-D varieties anymore; instead, the dimensioning is done
> through
> the datatypes used for their components. I realize that this presents a risk
> for
> incompatibilities, but it simplifies the model and an explicit dimension
> attribute has
> been added that is to be used to control this.
> Generic coordinates are provided to allow inclusion of anything other than
> the
> five astronomical coordinate types, such as temparature, pressure, flux
> density, etc.
>
> No package depends on frameTransforms and it depends only on coordSystem.
> It comes in two varieties: as part of a pixel frame (pixel frames have to
> have a
> mapping onto the real world) and as a class that operates between two real
> world
> coordinate frames. Note that in either case the transform is defined as a
> mapping
> between coordinate frames. That means that the frame needs to have all
> information
> needed to define that mapping.
> There are two high-level design options for the transform.
> The one presented in this design closely mirrors FITS WCS: a single set of
> metadata
> parameters specifies the full transformation/mapping/projection from one
> coordinate
> frame to another. Translating between it and FITS WCS header keywords is
> straightforward.
> An alternative design is presented by Mark in the image data model: the
> frame
> transformations are atomic (scale, translate, rotate, project) and one has
> to string
> those elements together to effect the full transformation. The FITS WCS
> papers
> explain how their compound transformations are constructed.
> The choice between these two approaches is a bit of a toss-up (although
> undoubtedly
> there will be people on either side who will argue forcefully that one is
> clearly superior
> to the other). This, I think, is a matter for discussion.

The atomic transformations approach is much more flexible.  The
FITS-WCS "we've thought of everything" approach is unnecessarily
restrictive in the WCS schemes that can be created. The use of atomic
transformations allows people to invent new schemes as and when
needed, without needing to go though a long-winded consultation about
extending the standard. It's limited only by the range of atomic
transformations available in your toolkit.

It's like the difference between a language that defines a grammar and
a vocabulary of words that can be strung together in any legal manner,
compare to a language that only allows you to select whole sentences
from a limited set of allowed sentences.

David







> Note that enumerated coordinate values are supported. Polarization is an
> example
> of an enumerated coordinate axis.
>
> coordArea has a dependency on coordSystem and coords.
> region has a dependency on coordArea and coord, for obvious reasons.
>
> Enjoy!
>
>   - Arnold
>
> -------------------------------------------------------------------------------------------------------------
> Arnold H. Rots                                          Chandra X-ray
> Science Center
> Smithsonian Astrophysical Observatory                   tel:  +1 617 496
> 7701
> 60 Garden Street, MS 67                                      fax:  +1 617
> 495 7356
> Cambridge, MA 02138
> arots at cfa.harvard.edu
> USA
> http://hea-www.harvard.edu/~arots/
> --------------------------------------------------------------------------------------------------------------
>