1 / 40

A Tool-kit Approach to WCS

A Tool-kit Approach to WCS. David Berry (Starlink) IVOA Inter-operability Meeting Cambridge 12-16 th May 2003. Importance of WCS. WCS is needed to: Locate data within the region of interest Align data sets from disparate sources Annotate data displays. The “prescriptive” approach.

becky
Télécharger la présentation

A Tool-kit Approach to WCS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A Tool-kit Approach to WCS David Berry (Starlink) IVOA Inter-operability Meeting Cambridge 12-16th May 2003

  2. Importance of WCS WCS is needed to: • Locate data within the region of interest • Align data sets from disparate sources • Annotate data displays

  3. The “prescriptive” approach • Prescribes a limited number of allowed recipes which may be used to describethe relationships between specified co-ordinate systems. • As WCS needs change, new recipes need to be added – can end up with lots of “specific-case” code (does not scale well). • It can be difficult to reach agreement on what the allowed recipes should be.

  4. The “tool-kit” approach • Provides a wide range of simple WCS components (tools) which can be “connected together” in any way to create a complete WCS representation. • There are no prescribed recipes; the developer is free to use the most appropriate representation for the WCS information. • Components are self-describing.

  5. The AST library • An implementation of a tool-kit approach to WCS representation and management. • See http://www.ast.man.ac.uk/~dsb/ast/ast.html

  6. AST Base classes • The basic tools in the AST tool-kit are Mappings, Frames and FrameSets. • Each base class encapsulates the general properties and methods of the class – sub-classes are provided for specific case. • All can be serialised, for instance as XML.

  7. The Mapping class • A Mapping transforms a set of positions using a specified mathematical operation. • No assumptions are made about the nature of the input or output co-ordinate systems. • The input and output positions need not be of the same dimensionality. • Many (but not all) Mappings will be in invertible.

  8. Mapping sub-classes Sub-classes of Mapping are provided which implement: • Axis scaling • Shift of origin • Matrix multiplication • Spherical projections • Cartesian to spherical conversion

  9. Mapping sub-classes • Axis permutation and selection • Arbitrary algebraic expressions • Pin-cushion distortion • Transformations between celestial, spectral and (shortly) time co-ordinate systems, all based on SLALIB • Others can be added easily

  10. Map1 Map2 Map1 Map2 Compound Mappings • A CmpMap is a sub-class of Mapping which encapsulates two other Mappings. • Series CmpMaps: • Parallel CmpMaps:

  11. Map2 Map3 Map1 Map4 Compound Mappings • Since a CmpMapis itself a Mapping, a CmpMap can encapsulate other CmpMaps. • This allows arbitrarily complex Mappings to be constructed:

  12. The Frame class • A Frame describes a physical domain such as “the sky”, “a pixel array”, “a spectrum”, “time”, “a focal plane”, “3D space”, etc. • The base Frame class represents a basic N-dimensional Euclidean space which can be used to describe a user-specified domain. • Sub-classes of Frame exist to describe celestial and spectral positions (“time” to follow shortly).

  13. The Frame class • The description given by a Frame includes: • The domain name • The dimensionality of the domain • The particular co-ordinate system used to describe positions within the domain (sub-classes support a range of different co-ordinate systems appropriate to the sub-class domain) • A moment in time which specifies the co-ordinate system

  14. The Frame class • The description given by a Frame includes: • Label, Unit and Symbol strings for each axis of the co-ordinate system. • The topology of the domain (allows navigation around the domain) • The Mappings needed to transform between the different co-ordinate systems which can be used to describe positions within the domain.

  15. The SkyFrame • Describes positions on the sky • Co-ordinate systems currently supported include equatorial (FK4, FK4-NO-E, FK5, GAPPT, ICRF), ecliptic, galactic, super-galactic. Heliocentric systems to follow… • Extra properties: Equinox.

  16. A Serialised SkyFrame Begin SkyFrame # Description of celestial coordinate system # Title = "FK4 equatorial coordinates; mean equinox B1950.0; epoch B1987.67101 " # Title of coordinate system Naxes = 2 # Number of coordinate axes # Domain = "SKY" # Coordinate system domain Epoch = 1987.67 # Julian epoch of observation # Lbl1 = "Right ascension" # Label for axis 1 # Lbl2 = "Declination" # Label for axis 2 System = "FK4" # Coordinate system type # Uni1 = "hh:mm:ss.s" # Units for axis 1 # Uni2 = "ddd:mm:ss" # Units for axis 2 # Dir1 = 0 # Plot axis 1 in reverse direction # Bot2 = -1.5707963267949 # Lowest legal axis value # Top2 = 1.5707963267949 # Highest legal axis value Ax1 = # Axis number 1 Begin SkyAxis # Celestial coordinate axis End SkyAxis Ax2 = # Axis number 2 Begin SkyAxis # Celestial coordinate axis End SkyAxis IsA Frame # Coordinate system description Eqnox = 1950 # Besselian epoch of mean equinox End SkyFrame

  17. The SpecFrame • Describes positions within an electro-magnetic spectrum • Co-ordinate systems include frequency, wavelength, energy, velocity (radio, optical, relativistic), etc, all in any appropriate unit (including log, sqrt, units, etc). • Extra properties: Rest frame, observer position, source position, rest frequency, source velocity...

  18. A Serialised SpecFrame Begin SpecFrame # Description of spectral coordinate system # Title = "Frequency (lSRK)" # Title of coordinate system Naxes = 1 # Number of coordinate axes # Domain = "SPECTRUM" # Coordinate system domain Epoch = 1995.55138507871 # Julian epoch of observation # Lbl1 = "Frequency" # Label for axis 1 System = "FREQ" # Coordinate system type # Uni1 = "GHz" # Units for axis 1 Ax1 = # Axis number 1 Begin Axis # Coordinate axis Unit = "GHz" # Axis units End Axis IsA Frame # Coordinate system description SoR = "LSRK" # Standard of rest RefRA = 0.0286375917587126 # Reference RA (rads, FK5 J2000) RefDec = 0.0223112108219319 # Reference Dec (rads, FK5 J2000) GeoLat = 0.345973275091431 # Observers geodetic latitude (rads) GeoLon = -2.71358558214735 # Observers geodetic longitude (rads) RstFrq = 230537999000 # Rest frequency (Hz) SrcVel = 110000 # Source velocity (m/s) SrcVRF = "LSRK" # Source velocity rest frame UFreq = "GHz" # Preferred units for frequency End SpecFrame

  19. Compound Frames • The CmpFrame class combines two component Frames to form a Frame which describes two physical domains. • For instance, a spectral cube can be described by a CmpFrame which combines a SkyFrame and a SpecFrame. • Since a CmpFrame is itself a Frame, complex CmpFrames can be constructed which encapsulate other CmpFrames.

  20. The Convert method • Convert – a method of the Frame class, extended by sub-classes. • Returns a Mapping which converts positions in ‘this’ Frame into another supplied Frame, or a null reference if no conversion is possible. • Hides all details of conversion between different co-ordinate systems – a non-trivial task for CmpFrames!

  21. Putting it all together - FrameSets • A FrameSet is a network of Frames connected together by Mappings. • Each Frame represents one or more of the co-ordinate systems which can be used to describe the position of a data value. • Each Mapping describes how to transform a position from one Frame to another.

  22. XI-ETA-B PIXEL XI-ETA SKY-B SKY Map1 Map4 Map2 Map3 Putting it all together – FrameSets XI-ETA: Tangent plane standard co-ordinates without barrel distortion. SKY: RA/Dec without added barrel distortion. XI-ETA-B: Tangent plane standard co-ordinates with barrel distortion. SKY-B: RA/Dec with barrel distortion.

  23. The Convert method again • FrameSet inherits from Frame. When viewed as a Frame, a FrameSet is equivalent to its current Frame. • FrameSet extends the Frame.Convert method to find a Mapping which “aligns” two FrameSets: it uses the Convert method recursively on all pairs of Frames. • Even works with CmpFrames!

  24. The FindFrame method • Searches a FrameSet for a Frame with given properties. • A template Frame defines the required properties. • Properties may be left undefined in the template – they are used as “wild-cards”.

  25. An AST representation of FITS-WCS • An AST FrameSet can be automatically generated to describe the WCS information in a FITS header. Consider the following simple FITS header as an example: CRPIX1 = 256 / Pixel X coordinate of reference point CRPIX2 = 257 / Pixel Y coordinate of reference point CRVAL1 = 45.83 / RA (degs) at reference point CRVAL2 = 63.57 / Dec (degs) at reference point CTYPE1 = 'RA---TAN' / Gnomonic projection giving RA/DEC CTYPE2 = 'DEC—-TAN' / Gnomonic projection giving RA/DEC CD1_1 = -0.003 / Matrix which rotates and scales pixel CD1_2 = 0.0005 / coordinates into projection plane CD2_1 = -0.0005 / (X,Y) coordinates in degrees CD2_2 = 0.003 / RADESYS = 'FK5 ' / RA/DEC are in the FK5 frame EQUINOX = 2000.0 / Mean equator and equinox of J2000.0 MJD-OBS = 44258.7856 / Modified Julian Date at start of observation

  26. Map SKY PIXEL An AST representation of FITS-WCS • The example FITS header on the previous slide can be described using an AST FrameSet holding 2 Frames connected together by a Mapping. • These components are described over the next few slides…

  27. Map SKY PIXEL An AST representation of FITS-WCS • The “PIXEL” Frame represents the pixel array. Positions within the pixel array are described using the usual Cartesian FITS pixel co-ordinate system. • This Frame describes the input co-ordinates supplied to the Mapping.

  28. Map SKY PIXEL An AST representation of FITS-WCS • The “SKY” SkyFrame (a sub-class of Frame) represents the sky. Positions on the sky are described in the system specified by the FITS keywords CTYPEi, RADESYS, EQUINOX and MJD-OBS. • This SkyFrame describes the output co-ordinates produced by the Mapping.

  29. Map SKY PIXEL An AST representation of FITS-WCS • “Map” is a CmpMap (a compound Mapping) which combines several simpler atomic Mappings in series. • Each atomic Mapping represents a step in the FITS-WCS recipe for converting pixel positions into sky positions. These Mappings are described over the next few slides…

  30. Map1 PIXEL An AST representation of FITS-WCS • The first atomic Mapping is a WinMap which shifts the origin as described by the CRPIX1 & CRPIX2 FITS keywords. A WinMap is a sub-class of Mappingwhich maps a specified rectangular input window onto a specified output window by applying a linear scale and shift to each axis. The input to this Mapping is a position in the PIXEL Frame.

  31. Map1 Map2 PIXEL An AST representation of FITS-WCS • A WinMap which shifts the origin as described by the CRPIX1 & CRPIX2 keywords. • The second atomic Mapping is a MatrixMap which rotates and scales the axes as described by the CDi_j FITS keywords. A MatrixMap is a sub-class of Mappingwhich multiplies each input N-dimensional position by an M x N matrix to produce an M-dimensional output position.

  32. Map1 Map2 Map3 PIXEL An AST representation of FITS-WCS • A WinMap which shifts the origin as described by the CRPIX1 & CRPIX2 keywords. • The second atomic Mapping is a MatrixMap which rotates and scales the axes as described by the CDi_j FITS keywords. • The third atomic Mapping is a WcsMap which produces native longitude and latitude, using the spherical projection specified by the CTYPEi FITS keywords. A WcsMap is a sub-class of Mappingwhich can perform any of the FITS-WCS spherical projections.

  33. Map1 Map2 Map3 Map4 PIXEL An AST representation of FITS-WCS • A WinMap which shifts the origin as described by the CRPIX1 & CRPIX2 keywords. • The second atomic Mapping is a MatrixMap which rotates and scales the axes as described by the CDi_j FITS keywords. • The third atomic Mapping is a WcsMap which produces native longitude and latitude, using the spherical projection specified by the CTYPEi FITS keywords. • The fourth atomic Mapping is a SphMap which converts native longitude and latitude into corresponding Cartesian (X,Y,Z) values on a unit sphere. A SphMap is a sub-class of Mapping which performs spherical to Cartesian conversion.

  34. Map1 Map2 Map3 Map4 Map5 PIXEL An AST representation of FITS-WCS • A WinMap which shifts the origin as described by the CRPIX1 & CRPIX2 keywords. • A MatrixMap which rotates and scales the axes as described by the CDi_j FITS keywords. • A WcsMap which produces native longitude and latitude, using the spherical projection specified by the CTYPEi FITS keywords. • A SphMap which converts native longitude and latitude into corresponding Cartesian (X,Y,Z) values on a unit sphere. • The fifth Mapping is a 3x3 MatrixMap which does a 3-D rotation to put the RA/Dec position given by FITS keywords CRVALi at the reference point (with the default value for the LONPOLE keyword).

  35. Map1 Map2 Map3 Map4 Map5 Map6 PIXEL An AST representation of FITS-WCS • A WinMap which shifts the origin as described by the CRPIX1 & CRPIX2 keywords. • A MatrixMap which rotates and scales the axes as described by the CDi_j FITS keywords. • A WcsMap which produces native longitude and latitude, using the spherical projection specified by the CTYPEi FITS keywords. • A SphMap which converts native longitude and latitude into corresponding Cartesian (X,Y,Z) values on a unit sphere. • A 3x3 MatrixMap which does a 3-D rotation to put the RA/Dec position given by FITS keywords CRVALi at the reference point. • The final Mapping is an inverted SphMap which converts Cartesian (X,Y,Z) values back into longitude (RA) and latitude (Dec).

  36. Map1 Map2 Map3 Map4 Map5 SKY PIXEL Map6 An AST representation of FITS-WCS • A WinMap which shifts the origin as described by the CRPIX1 & CRPIX2 keywords. • A MatrixMap which rotates and scales the axes as described by the CDi_j FITS keywords. • A WcsMap which produces native longitude and latitude, using the spherical projection specified by the CTYPEi FITS keywords. • A SphMap which converts native longitude and latitude into corresponding Cartesian (X,Y,Z) values on a unit sphere. • A 3x3 MatrixMap which does a 3-D rotation to put the RA/Dec position given by FITS keywords CRVALi at the reference point. • An inverted SphMap which converts Cartesian (X,Y,Z) values back into longitude (RA) and latitude (Dec). The output from this final Mapping is the required RA/Dec position.

  37. WCSNAMEA WCSNAMEB WCSNAMEC MapA MapB MapC PIXEL An AST representation of FITS-WCS • FITS header which have alternate axis descriptions can be represented by a more complicated FrameSet as shown above.

  38. Benefits of the “tool-kit” approach to WCS • Flexibility: provides a wider range of options for describing novel WCS arrangements. • Abstract interface: Frame methods can be used on any class of Frame so general purpose applications can be written which know nothing about the details of the WCS. • Scalability: Complex WCS arrangement can be extended simply by adding new Frames.

  39. Benefits of the “tool-kit” approach to WCS • Scalability: New classes of Frame and Mapping can be added and used without need for application code to be changed. • Functionality: Allows powerful methods such as Convert and FindFrame to be written. • Ease of use: Hides all the specific details of different co-ordinate systems and the conversions between them.

  40. Conclusions • Tool-kit approaches to WCS description and management ease future development as WCS requirements evolve. • The description and handling of co-ordinate systems crops up in many areas of VO work. Adoption of a single unified system would reduce integration issues and the over-all development effort.

More Related