IVOA DM Work Package : Units description and usage

• lead Anita Richards with help from MireilleLouys

Goal

The material below is a starting point for discussion; I apologise if I have omitted existing efforts, please add references and/or a brief outline. Nothing so far below is policy, just ideas for criticism/replacement.

Approach

How do we find out what are VO priorities?

• What units do major data providers use?
  • Existing codings and definitions
• What units do users want? (literature search?)
  • Need to strike a balance between being user-friendly and excessively complex models
• Establish use cases to define the minimum requirements for use of units in VO data models and applications.
• Produce preliminary requirements document
• Use test implimentations
• Check for consistency between IAU and CDS and other widely used current standards
• Develop

Existing Documents

• Standards
  • Standards for Astronomical Catalogues, Version 2.0
  • IAU Recommendations concerning Units from the IAU Style Manual by G.A. Wilkins (1989)
  • NIST (National Institute of Standards & Technology) project UnitsXML from MarieLiseDubernet
    • note This looks very useful for SI and a few other units. It is not clear if it covers astronomical units but it states that it is designed to be used alongside other namespaces. This could be the starting point for technical developers? AnitaRichards
  • Type `units' in many types of Linux
• Discussion/implementation
  • Comparison between IAU recommendations, VizieR, HEASARC and the GNU software Units from SebastienDerriere
    • note This does not look too bad, as regards being possible to provide schemata for synonyms of the commonest SI and astronomical units - apart from a few degeneracies. AnitaRichards
  • Section 4 in Greisen and Calabretta 2002, A&A 395, 1061 - see Specification of Physical Units within OGIP FITS files (not only relevant to FITS)
  • VOSpec model - described in Dimensional Analysis applied to Spectrum Handling in VO context (Osuna & Salgado)
  • check SpecView...
  • Unit strings allowed in STC from ArnoldRots

Where are units needed?

Construction of Spectral Energy Distributions

The use of units and interconversions has been well-developed e.g. in VOSpec and YAFIT, but consistency is due to the cooperation of the individuals involved. A model for units would recognise this effort and allow it to be applied more widely.

TAP - source catalogue DM - need to compare quantities

SPECFIND : A tool to extract cross-identifications and radio continuum spectra from radio catalogues contained in the VIZIER database of the CDS.
Reference: SPECFIND Catalog of radio continuum spectra
Authors: Vollmer, B.; Davoust, E.; Dubois, P.; Genova, F.; Ochsenbein, F.; van Driel, W.
Publication: VizieR On-line Data Catalog: VIII/74.

Cone, S?AP, registry searches

The current IVOA standards mandate units, but in some cases this repeatedly leads to problems e.g..

• Cone search/SIAP radius - decimal degrees
  • Anomalous results are often obtained due to a service returning a region in other units (e.g. 0.1 arcmin instead of degree) (see DB queries below).
• Spectral region - wavelength in metres
  • Conversion from frequency and energy units is non-linear. Whilst this is trivial (and rounding errors are unimportant) for single simple regions, it makes it hard to describe the spectral resolution with a single number, if it is e.g. 1 MHz in regions between 1 and 30 GHz.

Conversion tools

• Flux unit conversions e.g. VOSpec, tools using the STILTS library
• Coordinate conversions (B1950 RA-Dec to J2000 glat-glon etc.) e.g. tools using the STILTS library, SIMBAD services etc.

Database queries

• Cone searches have mandated units (see below)
• ADQL users have to know what units to use for the query parameters. How can they check this?

Lessons so far

Dimensional approach (see VOSpec)

Services with mandated units

Many data publishers install VO services on top of existing archives in arbitrary units. We can't expect the astronomical users to know what that is so e.g. SIAP search areas are always supposed to be in decimal degrees, but this often comes unstuck if data are in other units. What is best:

• Make it easy/persuade data providers forcibly to supply information in the correct units. This would probably be feasible for data bases but near-impossible for FITS and other observed data (unless it was accessed via a database). Not all data providers would comply and either just ignor the requirement or not provide their data.
• Find a way to insert a unit conversion tool in the query path (complicates the S?APs)

Conversions

It is important to define the limits of accuracy e.g.

• Magnitude-flux - even if all observational quantities e.g. the zero-points are supplied, accuracy is limited to a few percent unless corrections like the colour of individual objects are included.
• Positional coordinates - .epoch as well as equinox; leap seconds etc. needed for milli-arcsec accuracy.

We eventually need to be able to convert any units as accuracy as possible but often the full information is not available, so tools need to be flexible and settle for lower accuracy where unavoidable.

Models for units could include

• Simple formulae (but where is maths done? Limitations inside DBs)
• Look-up tables (where?)
• More sophisticated references to services, links with references in data etc.

Results and Feedback

• Comment from discussion: scope is to enable non-linear conversions (like freq-wavelength), not to include the mechanism in the Units model. That is, we should look at the requirements of the existing tools, not duplicate them.

Interactions with other WG efforts

• IVOA VO Query Language

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->