IVOA Interop Kyoto - DM1 Space-Time Coordinate Metadata: Status Arnold Rots Harvard-Smithsonian CfA / CXC T HE US N ATIONAL V IRTUAL O BSERVATORY

IVOA Interop Kyoto - DM2 Requirement The requirement for Space-Time Coordinate metadata is that they: –provide sufficient and necessary information –are self-consistent We need to assure that coordinate transformations can be performed

IVOA Interop Kyoto - DM3 Implementations STC-X: XML schemata current version: 1.20 STC-S: String version used in Resource Metadata

IVOA Interop Kyoto - DM4 Status STC is in the Proposed Recommendation stage A number of (mostly minor) points came up at the VOEvent meeting, mainly affecting STC-X implementation More comments came from VOTable Currently being incorporated in Version 1.22 Coordination with Characterization Coordination with Quantity

IVOA Interop Kyoto - DM5 Enhancements Name in coordinates optional TimeScale optional in AstroTime XInclude examples AstroCoordArea optional for ObsLocation Error circles Epoch IDs STC-S has been incorporated in Resource Metadata and SkyNode David Berry is hard at work on coordinate transformations using AST

IVOA Interop Kyoto - DM6 Musings It would really be good to have an accepted set of XML Schema best practices for IVOA Establishment of a review board for XML schemata?

IVOA Interop Kyoto - DM7 XInclude The physical XML documents can be simplified through use of XInclude files that allow inclusion of frequently used elements, referenced through standardized IDREFs –Constructors can just insert the single lines –Parsers that do not care about coordinate systems or observatory positions can just ignore them and optionally rely on the IDREFs, while the document remains rigorously correct

IVOA Interop Kyoto - DM8 XInclude Issues Its a beautiful idea to pre-define coordinate systems, but is it worth it? –SpaceFrame: ICRS, FK4, FK4, GAL, SGAL, ECL, GEOD, GEOC –SpaceReference: TOPO, BARY, GEO –TimeFrame: TT, UTC –TimeReference: TOPO, BARY, GEO –SpectralReference: TOPO, GEO, BARY –Redshift: OPT, RAD; Z, DOPVEL –RedshiftReference: TOPO, GEO, BARY, LSR Adds up to > 800

IVOA Interop Kyoto - DM9 Issues to be Resolved What Frames are required (Time & Space?) Handling of namespaces Should Observatory and Observation Location be uncoupled? Should multiple Observations and/or multiple coordinates be allowed? IDs for all leaves, allowing linking in either direction Unions versus Substitution Groups versus xsi:type – general XML schema best practices questions Grey area between error box and Region

IVOA Interop Kyoto - DM10 Overview Justification: what is driving this? The simple requirements Design: how do we solve this? Implementation Next - issues

IVOA Interop Kyoto - DM11 Scope The following coordinate axes are closely intertwined: –Space –Time –Spectral (frequency, wavelength, energy) –Redshift (Doppler velocity) Time is bound to a position and positions are time-variable Spectral and redshift data are tied to reference frames that may or may not be time-variable

IVOA Interop Kyoto - DM12 Scope (2) Context-dependent defaults are fine –Issues are well-defined and clear for single- observatory observations – even when not all is explicitly specified But there are no global defaults –In the VO all implicit assumptions need to be made explicit since they will not be obvious anymore One must be able to transform the coordinates of two observations to a common coordinate system –Including far-field/near-field transformations

IVOA Interop Kyoto - DM13 The Metadata Components Coordinate system –Consists of one or more frames Frames typically consist of a reference position (origin) and a reference frame Coordinate values –Refers to a coordinate system Coordinate areas or ranges –To define a volume in coordinate space –Special case: Regions Specifically for spatial coordinates

IVOA Interop Kyoto - DM14 Coordinate System Time frame –Reference position & time scale Spatial frame –Reference position and coordinate frame Spectral frame –Reference position in phase space Redshift frame –Definition and reference position

IVOA Interop Kyoto - DM15 Reference Frames and Positions Examples of spatial Reference Frames: –FK4, FK5, ICRS, Ecliptic, Galactic, Geocentric, Geodetic, various solar and planetary frames, unknown, custom, … Time scales: –TT, TAI, UTC, TDB, TEB, TCG, TCB, … Reference Positions: –Topocenter, Geocenter, Heliocenter, Barycenter, Galactic center, LSR-K, LSR-D, planetary centers, unknown, custom, …

IVOA Interop Kyoto - DM16 Coordinates A coordinate object contains a reference to a coordinate system It is a composite object that may hold –Name- Resolution –Value- Size –Error- Pixel size All quantities are scalar except for spatial (>1D) –In that case errors and resolutions get more complicated All coordinates include their units Spatial may include position and velocity (PM) Time has options (absolute or elapsed)

IVOA Interop Kyoto - DM17 Coordinate Area Defines the volume in coordinate space that is represented Consists of one or more ranges in individual coordinates Spatial position has more options –Sphere –2-D Regions Shapes: polygon, sector, ellipse, convex, convex hull Operations: intersection, union, negation

IVOA Interop Kyoto - DM18 CatalogEntry A simple catalog of positions:

IVOA Interop Kyoto - DM19 AstroCoordSystem One could optionally add a SpectralFrame TT

IVOA Interop Kyoto - DM20 AstroCoordSystem (2) The coordinate system may also be specified through an XInclude:

IVOA Interop Kyoto - DM21 AstroCoords The position vector points to an element with ID=Column3 – presumably a Field in the document that describes column 3 of the table; in addition, an error is given Column

IVOA Interop Kyoto - DM22 AstroCoordArea This element is not required, but it is a mechanism to provide information on the coverage of the catalog T00:00: T00:00:00

IVOA Interop Kyoto - DM23 AstroCoordsArea (2) Time interval is only for illustrative purposes; only position may be useful; one could optionally add a spectral interval

IVOA Interop Kyoto - DM24 Extensibility This was a simple example; the system can be extended to handle more sophisticated catalogs: –Multiple coordinate systems (e.g., l,b) –More coordinate axes: Proper motions Redshifts, radial velocities Spectral information Temporal information –Additional information: errors, sizes, etc. –Merged catalogs