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