IVOA DM Work Package : Units description and usage

• lead Anita Richards
• units final VO standard to be achieved with the Semantic WG

Latest

DiscussionOnVOUnits : Discussion on specific aspects of the document 1.0.

WD-VOUnits-1.0-20111216.pdf 2011 December 16 - first release of Version 1.0

WD-VOUnits-v0.3-20110508.pdf 2011 May 08 draft IVOA Note minor update

WD-VOUnits-v0.2-20090522.pdf 2009 May 22 draft IVOA Note

2009 March Draft IVOA working draft

ImplicationsForADQL 2009Mar18

OldUnitsPage

Main IvoaDataModel page

Goal

Existing Documents

• Standards
  • Standards for Astronomical Catalogues, Version 2.0
  • Type `units' in many types of Linux
  • IAU Recommendations concerning Units from the IAU Style Manual by G.A. Wilkins (1989)
    • Symbols unsuitable for the IVOA as they use Greek letters, diacritical marks etc. which are not easy to use in machine-readable documents; escaped versions could be error-prone. These are not in general used within data (as distinct from free text) anyway.
• Comparison between IAU recommendations, VizieR, HEASARC and the GNU software Units from SebastienDerriere
• Existing VO usage
  • VOSpec model - described in Dimensional Analysis applied to Spectrum Handling in VO context (Osuna & Salgado)
  • Unit strings allowed in STC from ArnoldRots
• CDS has a library for units manipulation. An on-line tool to interpret units is also available (based on recognized symbols). This library has beed used in tools like:
  • MEx, for FITS keyword mapping
  • An homogenized data extraction tool (most suited for VizieR catalogues)
• More:
  • NIST (National Institute of Standards & Technology) project UnitsXML from MarieLiseDubernet
  • FITS FITS references page, development.
    • In the new FITS standard, look at section 4.3 of the v3.0 PDF file (pp.31-36 in the PDF, numbered pp.24-28 in the document)
    • 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)
  • On-line unit conversion:
    • AST Unit Mapper
    • VizieR units

Recommendations

As discussed at IVOA, Trieste, May 2008

• Goal: to provide suitable tools - Backus Naur form?, libraries and references to allow
  • Recognition of units in use by the members of IVOA
  • Simple (mostly linear) conversions such as metres/parsec; use of SI prefixes (k,M,G eetc.) to avoid bulky numbers or damaged precision.
• Whatever is adopted should as far as possible be compatible with existing VO implimentatations and FITS, and should cover all the relevant IAU types of unit (as distinct from the unsuitable symbols).
  • Please nominate whichever you consider to be the most complete existing system The IVOA should provide translation where there are unambiguous variations in other systems, including from FITS keywords (making use of existing tools/libraries where possible).
• Please identify any serious ambiguities e.g. k could be kilo- or Boltzmann's constant, and suggestions for how to overcome this (recognise by context? Flag for human intervention?).
• Produce web page of links to existing tools for unit handling, conversion, dimensional analysis etc.
  • Example from CDS pages: see Unit conversion link - but in a form which can be linked to user programs or packages in C, IDL, python etc. with simple instructions
• Educate next generation of data providers to use some standard for units!
• Need to record date and reference to values of fundamental quantities where available.
• How far can we go with dimensional analysis? Are there so few cases where it breaks down that these can be handled individually, and if so how does code recognise them (e.g. the Hubble constant, in km/s per Mpc) - or can we specify limited situations where dimensional analysis is adequate?

Use cases

1. TAP - source catalogue DM - need to compare quantities please elaborate
2. 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.
   please elaborate - is this a requirequirement for conversion between physical flux units e.g. mJy, Jy, W m-2 Hz-1 - what about Jy beam-1 (if you are lucky the beam size is given conveniently...?
3. Cone, S?AP, registry searches
   • The current IVOA standards mandate units, but this leads to frequent problems due to to a Cone search/SIAP service returning a region in different units from the one the user thinks they are using (e.g. 0.1 arcmin instead of degree) (see DB queries below).
4. Database queries: We have no control over the units used by data providers (?). We do need to be able to recognise them.
   • Example inspired by Jeff Lusted: What can ADQL do about units for synthetic columns? E.g.

     SELECT a.fint/(a.maj*a."min") 
      as fluxdensity from firstSource as a

     where fint has units of mJy and maj and min have units of arcsec so fluxdensity has units of mJy arcsec-2
   • More complicated cases:
     • In the above case, strictly speaking the divisor should be (a.maj*a.min/4*ln2)

     • SELECT 365.25*a.dist_opt/(a.jdate-2450975.0) 
        as propermotion FROM twomass_psc as a

       where the inputs have units of arcsec and Julian Days (implicit for 2450975.0) but the user wants output in arcsec per year ...
5. Enabling convenient image display with axes labeled in user-specified units/sensible SI multiples.
6. Complex conversions e.g. magnitudes to physical units, are outside our scope but well-defined physical units should make that workpackage easier.
   • 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.
   • Conversion between wavelength and frequency/energy units is non-linear (even without observational issues). Whilst this is trivial (and rounding errors are unimportant) for single simple regions, it makes it hard to describe a spectral resolution of 1 MHz between 1 and 30 GHz, with a single number in wavlength units.

Interactions with other WG efforts

• IVOA VO Query Language

UnitsMir_fichiers

IVOA DM Work Package : Units description and usage

• lead Anita Richards
• units final VO standard to be achieved with the Semantic WG

Latest

WD-VOUnits-v0.2-20090522.pdf 2009 May 22 draft IVOA Note

2009 March Draft IVOA working draft

ImplicationsForADQL 2009Mar18

OldUnitsPage

Main IvoaDataModel page

Goal

Existing Documents

• Standards
  • Standards for Astronomical Catalogues, Version 2.0
  • Type `units' in many types of Linux
  • IAU Recommendations concerning Units from the IAU Style Manual by G.A. Wilkins (1989)
    • Symbols unsuitable for the IVOA as they use Greek letters, diacritical marks etc. which are not easy to use in machine-readable documents; escaped versions could be error-prone. These are not in general used within data (as distinct from free text) anyway.
• Comparison between IAU recommendations, VizieR, HEASARC and the GNU software Units from SebastienDerriere
• Existing VO usage
  • VOSpec model - described in Dimensional Analysis applied to Spectrum Handling in VO context (Osuna & Salgado)
  • Unit strings allowed in STC from ArnoldRots
• CDS has a library for units manipulation. An on-line tool to interpret units is also available (based on recognized symbols). This library has beed used in tools like:
  • MEx, for FITS keyword mapping
  • An homogenized data extraction tool (most suited for VizieR catalogues)
• More:
  • NIST (National Institute of Standards & Technology) project UnitsXML from MarieLiseDubernet
  • FITS FITS references page, development.
    • In the new FITS standard, look at section 4.3 of the v3.0 PDF file (pp.31-36 in the PDF, numbered pp.24-28 in the document)
    • 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)
  • On-line unit conversion:
    • AST Unit Mapper
    • VizieR units

Recommendations

As discussed at IVOA, Trieste, May 2008

• Goal: to provide suitable tools - Backus Naur form?, libraries and references to allow
  • Recognition of units in use by the members of IVOA
  • Simple (mostly linear) conversions such as metres/parsec; use of SI prefixes (k,M,G eetc.) to avoid bulky numbers or damaged precision.
• Whatever is adopted should as far as possible be compatible with existing VO implimentatations and FITS, and should cover all the relevant IAU types of unit (as distinct from the unsuitable symbols).
  • Please nominate whichever you consider to be the most complete existing system The IVOA should provide translation where there are unambiguous variations in other systems, including from FITS keywords (making use of existing tools/libraries where possible).
• Please identify any serious ambiguities e.g. k could be kilo- or Boltzmann's constant, and suggestions for how to overcome this (recognise by context? Flag for human intervention?).
• Produce web page of links to existing tools for unit handling, conversion, dimensional analysis etc.
  • Example from CDS pages: see Unit conversion link - but in a form which can be linked to user programs or packages in C, IDL, python etc. with simple instructions
• Educate next generation of data providers to use some standard for units!
• Need to record date and reference to values of fundamental quantities where available.
• How far can we go with dimensional analysis? Are there so few cases where it breaks down that these can be handled individually, and if so how does code recognise them (e.g. the Hubble constant, in km/s per Mpc) - or can we specify limited situations where dimensional analysis is adequate?

Use cases

1. TAP - source catalogue DM - need to compare quantities please elaborate
2. 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.
   please elaborate - is this a requirequirement for conversion between physical flux units e.g. mJy, Jy, W m-2 Hz-1 - what about Jy beam-1 (if you are lucky the beam size is given conveniently...?
3. Cone, S?AP, registry searches
   • The current IVOA standards mandate units, but this leads to frequent problems due to to a Cone search/SIAP service returning a region in different units from the one the user thinks they are using (e.g. 0.1 arcmin instead of degree) (see DB queries below).
4. Database queries: We have no control over the units used by data providers (?). We do need to be able to recognise them.
   • Example inspired by Jeff Lusted: What can ADQL do about units for synthetic columns? E.g.

     SELECT a.fint/(a.maj*a."min") 
      as fluxdensity from firstSource as a

     where fint has units of mJy and maj and min have units of arcsec so fluxdensity has units of mJy arcsec-2
   • More complicated cases:
     • In the above case, strictly speaking the divisor should be (a.maj*a.min/4*ln2)

     • SELECT 365.25*a.dist_opt/(a.jdate-2450975.0) 
        as propermotion FROM twomass_psc as a

       where the inputs have units of arcsec and Julian Days (implicit for 2450975.0) but the user wants output in arcsec per year ...
5. Enabling convenient image display with axes labeled in user-specified units/sensible SI multiples.
6. Complex conversions e.g. magnitudes to physical units, are outside our scope but well-defined physical units should make that workpackage easier.
   • 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.
   • Conversion between wavelength and frequency/energy units is non-linear (even without observational issues). Whilst this is trivial (and rounding errors are unimportant) for single simple regions, it makes it hard to describe a spectral resolution of 1 MHz between 1 and 30 GHz, with a single number in wavlength units.

Interactions with other WG efforts

• IVOA VO Query Language

UnitsMir_fichiers

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

IVOA DM Work Package : Units description and usage

• lead Anita Richards
• units final VO standard to be achieved with the Semantic WG

Latest

WD-VOUnits-v0.2-20090522.pdf 2009 May 22 draft IVOA Note

2009 March Draft IVOA working draft

ImplicationsForADQL 2009Mar18

OldUnitsPage

Main IvoaDataModel page

Goal

Existing Documents

• Standards
  • Standards for Astronomical Catalogues, Version 2.0
  • Type `units' in many types of Linux
  • IAU Recommendations concerning Units from the IAU Style Manual by G.A. Wilkins (1989)
    • Symbols unsuitable for the IVOA as they use Greek letters, diacritical marks etc. which are not easy to use in machine-readable documents; escaped versions could be error-prone. These are not in general used within data (as distinct from free text) anyway.
• Comparison between IAU recommendations, VizieR, HEASARC and the GNU software Units from SebastienDerriere
• Existing VO usage
  • VOSpec model - described in Dimensional Analysis applied to Spectrum Handling in VO context (Osuna & Salgado)
  • Unit strings allowed in STC from ArnoldRots
• CDS has a library for units manipulation. An on-line tool to interpret units is also available (based on recognized symbols). This library has beed used in tools like:
  • MEx, for FITS keyword mapping
  • An homogenized data extraction tool (most suited for VizieR catalogues)
• More:
  • NIST (National Institute of Standards & Technology) project UnitsXML from MarieLiseDubernet
  • FITS FITS references page, development.
    • In the new FITS standard, look at section 4.3 of the v3.0 PDF file (pp.31-36 in the PDF, numbered pp.24-28 in the document)
    • 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)
  • On-line unit conversion:
    • AST Unit Mapper
    • VizieR units

Recommendations

As discussed at IVOA, Trieste, May 2008

• Goal: to provide suitable tools - Backus Naur form?, libraries and references to allow
  • Recognition of units in use by the members of IVOA
  • Simple (mostly linear) conversions such as metres/parsec; use of SI prefixes (k,M,G eetc.) to avoid bulky numbers or damaged precision.
• Whatever is adopted should as far as possible be compatible with existing VO implimentatations and FITS, and should cover all the relevant IAU types of unit (as distinct from the unsuitable symbols).
  • Please nominate whichever you consider to be the most complete existing system The IVOA should provide translation where there are unambiguous variations in other systems, including from FITS keywords (making use of existing tools/libraries where possible).
• Please identify any serious ambiguities e.g. k could be kilo- or Boltzmann's constant, and suggestions for how to overcome this (recognise by context? Flag for human intervention?).
• Produce web page of links to existing tools for unit handling, conversion, dimensional analysis etc.
  • Example from CDS pages: see Unit conversion link - but in a form which can be linked to user programs or packages in C, IDL, python etc. with simple instructions
• Educate next generation of data providers to use some standard for units!
• Need to record date and reference to values of fundamental quantities where available.
• How far can we go with dimensional analysis? Are there so few cases where it breaks down that these can be handled individually, and if so how does code recognise them (e.g. the Hubble constant, in km/s per Mpc) - or can we specify limited situations where dimensional analysis is adequate?

Use cases

1. TAP - source catalogue DM - need to compare quantities please elaborate
2. 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.
   please elaborate - is this a requirequirement for conversion between physical flux units e.g. mJy, Jy, W m-2 Hz-1 - what about Jy beam-1 (if you are lucky the beam size is given conveniently...?
3. Cone, S?AP, registry searches
   • The current IVOA standards mandate units, but this leads to frequent problems due to to a Cone search/SIAP service returning a region in different units from the one the user thinks they are using (e.g. 0.1 arcmin instead of degree) (see DB queries below).
4. Database queries: We have no control over the units used by data providers (?). We do need to be able to recognise them.
   • Example inspired by Jeff Lusted: What can ADQL do about units for synthetic columns? E.g.

     SELECT a.fint/(a.maj*a."min") 
      as fluxdensity from firstSource as a

     where fint has units of mJy and maj and min have units of arcsec so fluxdensity has units of mJy arcsec-2
   • More complicated cases:
     • In the above case, strictly speaking the divisor should be (a.maj*a.min/4*ln2)

     • SELECT 365.25*a.dist_opt/(a.jdate-2450975.0) 
        as propermotion FROM twomass_psc as a

       where the inputs have units of arcsec and Julian Days (implicit for 2450975.0) but the user wants output in arcsec per year ...
5. Enabling convenient image display with axes labeled in user-specified units/sensible SI multiples.
6. Complex conversions e.g. magnitudes to physical units, are outside our scope but well-defined physical units should make that workpackage easier.
   • 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.
   • Conversion between wavelength and frequency/energy units is non-linear (even without observational issues). Whilst this is trivial (and rounding errors are unimportant) for single simple regions, it makes it hard to describe a spectral resolution of 1 MHz between 1 and 30 GHz, with a single number in wavlength units.

Interactions with other WG efforts

• IVOA VO Query Language

UnitsMir_fichiers

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

IVOA DM Work Package : Units description and usage

• lead Anita Richards
• units final VO standard to be achieved with the Semantic WG

Latest

WD-VOUnits-v0.3-20110508.pdf 2011 May 08 draft IVOA Note minor update

WD-VOUnits-v0.2-20090522.pdf 2009 May 22 draft IVOA Note

2009 March Draft IVOA working draft

ImplicationsForADQL 2009Mar18

OldUnitsPage

Main IvoaDataModel page

Goal

Existing Documents

• Standards
  • Standards for Astronomical Catalogues, Version 2.0
  • Type `units' in many types of Linux
  • IAU Recommendations concerning Units from the IAU Style Manual by G.A. Wilkins (1989)
    • Symbols unsuitable for the IVOA as they use Greek letters, diacritical marks etc. which are not easy to use in machine-readable documents; escaped versions could be error-prone. These are not in general used within data (as distinct from free text) anyway.
• Comparison between IAU recommendations, VizieR, HEASARC and the GNU software Units from SebastienDerriere
• Existing VO usage
  • VOSpec model - described in Dimensional Analysis applied to Spectrum Handling in VO context (Osuna & Salgado)
  • Unit strings allowed in STC from ArnoldRots
• CDS has a library for units manipulation. An on-line tool to interpret units is also available (based on recognized symbols). This library has beed used in tools like:
  • MEx, for FITS keyword mapping
  • An homogenized data extraction tool (most suited for VizieR catalogues)
• More:
  • NIST (National Institute of Standards & Technology) project UnitsXML from MarieLiseDubernet
  • FITS FITS references page, development.
    • In the new FITS standard, look at section 4.3 of the v3.0 PDF file (pp.31-36 in the PDF, numbered pp.24-28 in the document)
    • 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)
  • On-line unit conversion:
    • AST Unit Mapper
    • VizieR units

Recommendations

As discussed at IVOA, Trieste, May 2008

• Goal: to provide suitable tools - Backus Naur form?, libraries and references to allow
  • Recognition of units in use by the members of IVOA
  • Simple (mostly linear) conversions such as metres/parsec; use of SI prefixes (k,M,G eetc.) to avoid bulky numbers or damaged precision.
• Whatever is adopted should as far as possible be compatible with existing VO implimentatations and FITS, and should cover all the relevant IAU types of unit (as distinct from the unsuitable symbols).
  • Please nominate whichever you consider to be the most complete existing system The IVOA should provide translation where there are unambiguous variations in other systems, including from FITS keywords (making use of existing tools/libraries where possible).
• Please identify any serious ambiguities e.g. k could be kilo- or Boltzmann's constant, and suggestions for how to overcome this (recognise by context? Flag for human intervention?).
• Produce web page of links to existing tools for unit handling, conversion, dimensional analysis etc.
  • Example from CDS pages: see Unit conversion link - but in a form which can be linked to user programs or packages in C, IDL, python etc. with simple instructions
• Educate next generation of data providers to use some standard for units!
• Need to record date and reference to values of fundamental quantities where available.
• How far can we go with dimensional analysis? Are there so few cases where it breaks down that these can be handled individually, and if so how does code recognise them (e.g. the Hubble constant, in km/s per Mpc) - or can we specify limited situations where dimensional analysis is adequate?

Use cases

1. TAP - source catalogue DM - need to compare quantities please elaborate
2. 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.
   please elaborate - is this a requirequirement for conversion between physical flux units e.g. mJy, Jy, W m-2 Hz-1 - what about Jy beam-1 (if you are lucky the beam size is given conveniently...?
3. Cone, S?AP, registry searches
   • The current IVOA standards mandate units, but this leads to frequent problems due to to a Cone search/SIAP service returning a region in different units from the one the user thinks they are using (e.g. 0.1 arcmin instead of degree) (see DB queries below).
4. Database queries: We have no control over the units used by data providers (?). We do need to be able to recognise them.
   • Example inspired by Jeff Lusted: What can ADQL do about units for synthetic columns? E.g.

     SELECT a.fint/(a.maj*a."min") 
      as fluxdensity from firstSource as a

     where fint has units of mJy and maj and min have units of arcsec so fluxdensity has units of mJy arcsec-2
   • More complicated cases:
     • In the above case, strictly speaking the divisor should be (a.maj*a.min/4*ln2)

     • SELECT 365.25*a.dist_opt/(a.jdate-2450975.0) 
        as propermotion FROM twomass_psc as a

       where the inputs have units of arcsec and Julian Days (implicit for 2450975.0) but the user wants output in arcsec per year ...
5. Enabling convenient image display with axes labeled in user-specified units/sensible SI multiples.
6. Complex conversions e.g. magnitudes to physical units, are outside our scope but well-defined physical units should make that workpackage easier.
   • 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.
   • Conversion between wavelength and frequency/energy units is non-linear (even without observational issues). Whilst this is trivial (and rounding errors are unimportant) for single simple regions, it makes it hard to describe a spectral resolution of 1 MHz between 1 and 30 GHz, with a single number in wavlength units.

Interactions with other WG efforts

• IVOA VO Query Language

UnitsMir_fichiers

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

IVOA DM Work Package : Units description and usage

• lead Anita Richards

Latest

2009 March Draft IVOA working draft

ImplicationsForADQL 2009Mar18

OldUnitsPage

Main IvoaDataModel page

Goal

Existing Documents

• Standards
  • Standards for Astronomical Catalogues, Version 2.0
  • Type `units' in many types of Linux
  • IAU Recommendations concerning Units from the IAU Style Manual by G.A. Wilkins (1989)
    • Symbols unsuitable for the IVOA as they use Greek letters, diacritical marks etc. which are not easy to use in machine-readable documents; escaped versions could be error-prone. These are not in general used within data (as distinct from free text) anyway.
• Comparison between IAU recommendations, VizieR, HEASARC and the GNU software Units from SebastienDerriere
• Existing VO usage
  • VOSpec model - described in Dimensional Analysis applied to Spectrum Handling in VO context (Osuna & Salgado)
  • Unit strings allowed in STC from ArnoldRots
• CDS has a library for units manipulation. An on-line tool to interpret units is also available (based on recognized symbols). This library has beed used in tools like:
  • MEx, for FITS keyword mapping
  • An homogenized data extraction tool (most suited for VizieR catalogues)
• More:
  • NIST (National Institute of Standards & Technology) project UnitsXML from MarieLiseDubernet
  • FITS FITS references page, development.
    • In the new FITS standard, look at section 4.3 of the v3.0 PDF file (pp.31-36 in the PDF, numbered pp.24-28 in the document)
    • 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)
  • On-line unit conversion:
    • AST Unit Mapper
    • VizieR units

Recommendations

As discussed at IVOA, Trieste, May 2008

• Goal: to provide suitable tools - Backus Naur form?, libraries and references to allow
  • Recognition of units in use by the members of IVOA
  • Simple (mostly linear) conversions such as metres/parsec; use of SI prefixes (k,M,G eetc.) to avoid bulky numbers or damaged precision.
• Whatever is adopted should as far as possible be compatible with existing VO implimentatations and FITS, and should cover all the relevant IAU types of unit (as distinct from the unsuitable symbols).
  • Please nominate whichever you consider to be the most complete existing system The IVOA should provide translation where there are unambiguous variations in other systems, including from FITS keywords (making use of existing tools/libraries where possible).
• Please identify any serious ambiguities e.g. k could be kilo- or Boltzmann's constant, and suggestions for how to overcome this (recognise by context? Flag for human intervention?).
• Produce web page of links to existing tools for unit handling, conversion, dimensional analysis etc.
  • Example from CDS pages: see Unit conversion link - but in a form which can be linked to user programs or packages in C, IDL, python etc. with simple instructions
• Educate next generation of data providers to use some standard for units!
• Need to record date and reference to values of fundamental quantities where available.
• How far can we go with dimensional analysis? Are there so few cases where it breaks down that these can be handled individually, and if so how does code recognise them (e.g. the Hubble constant, in km/s per Mpc) - or can we specify limited situations where dimensional analysis is adequate?

Use cases

1. TAP - source catalogue DM - need to compare quantities please elaborate
2. 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.
   please elaborate - is this a requirequirement for conversion between physical flux units e.g. mJy, Jy, W m-2 Hz-1 - what about Jy beam-1 (if you are lucky the beam size is given conveniently...?
3. Cone, S?AP, registry searches
   • The current IVOA standards mandate units, but this leads to frequent problems due to to a Cone search/SIAP service returning a region in different units from the one the user thinks they are using (e.g. 0.1 arcmin instead of degree) (see DB queries below).
4. Database queries: We have no control over the units used by data providers (?). We do need to be able to recognise them.
   • Example inspired by Jeff Lusted: What can ADQL do about units for synthetic columns? E.g.

     SELECT a.fint/(a.maj*a."min") 
      as fluxdensity from firstSource as a

     where fint has units of mJy and maj and min have units of arcsec so fluxdensity has units of mJy arcsec-2
   • More complicated cases:
     • In the above case, strictly speaking the divisor should be (a.maj*a.min/4*ln2)

     • SELECT 365.25*a.dist_opt/(a.jdate-2450975.0) 
        as propermotion FROM twomass_psc as a

       where the inputs have units of arcsec and Julian Days (implicit for 2450975.0) but the user wants output in arcsec per year ...
5. Enabling convenient image display with axes labeled in user-specified units/sensible SI multiples.
6. Complex conversions e.g. magnitudes to physical units, are outside our scope but well-defined physical units should make that workpackage easier.
   • 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.
   • Conversion between wavelength and frequency/energy units is non-linear (even without observational issues). Whilst this is trivial (and rounding errors are unimportant) for single simple regions, it makes it hard to describe a spectral resolution of 1 MHz between 1 and 30 GHz, with a single number in wavlength units.

Interactions with other WG efforts

• IVOA VO Query Language

UnitsMir_fichiers

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

IVOA DM Work Package : Units description and usage

• lead Anita Richards

Latest

WD-VOUnits-v0.2-20090522.pdf 2009 May 22 draft IVOA Note

2009 March Draft IVOA working draft

ImplicationsForADQL 2009Mar18

OldUnitsPage

Main IvoaDataModel page

Goal

Existing Documents

• Standards
  • Standards for Astronomical Catalogues, Version 2.0
  • Type `units' in many types of Linux
  • IAU Recommendations concerning Units from the IAU Style Manual by G.A. Wilkins (1989)
    • Symbols unsuitable for the IVOA as they use Greek letters, diacritical marks etc. which are not easy to use in machine-readable documents; escaped versions could be error-prone. These are not in general used within data (as distinct from free text) anyway.
• Comparison between IAU recommendations, VizieR, HEASARC and the GNU software Units from SebastienDerriere
• Existing VO usage
  • VOSpec model - described in Dimensional Analysis applied to Spectrum Handling in VO context (Osuna & Salgado)
  • Unit strings allowed in STC from ArnoldRots
• CDS has a library for units manipulation. An on-line tool to interpret units is also available (based on recognized symbols). This library has beed used in tools like:
  • MEx, for FITS keyword mapping
  • An homogenized data extraction tool (most suited for VizieR catalogues)
• More:
  • NIST (National Institute of Standards & Technology) project UnitsXML from MarieLiseDubernet

• • • 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)

Recommendations

As discussed at IVOA, Trieste, May 2008

• Goal: to provide suitable tools - Backus Naur form?, libraries and references to allow
  • Recognition of units in use by the members of IVOA
  • Simple (mostly linear) conversions such as metres/parsec; use of SI prefixes (k,M,G eetc.) to avoid bulky numbers or damaged precision.
• Whatever is adopted should as far as possible be compatible with existing VO implimentatations and FITS, and should cover all the relevant IAU types of unit (as distinct from the unsuitable symbols).
  • Please nominate whichever you consider to be the most complete existing system The IVOA should provide translation where there are unambiguous variations in other systems, including from FITS keywords (making use of existing tools/libraries where possible).
• Please identify any serious ambiguities e.g. k could be kilo- or Boltzmann's constant, and suggestions for how to overcome this (recognise by context? Flag for human intervention?).
• Produce web page of links to existing tools for unit handling, conversion, dimensional analysis etc.
  • Example from CDS pages: see Unit conversion link - but in a form which can be linked to user programs or packages in C, IDL, python etc. with simple instructions
• Educate next generation of data providers to use some standard for units!
• Need to record date and reference to values of fundamental quantities where available.
• How far can we go with dimensional analysis? Are there so few cases where it breaks down that these can be handled individually, and if so how does code recognise them (e.g. the Hubble constant, in km/s per Mpc) - or can we specify limited situations where dimensional analysis is adequate?

Use cases

1. TAP - source catalogue DM - need to compare quantities please elaborate
2. 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.
   please elaborate - is this a requirequirement for conversion between physical flux units e.g. mJy, Jy, W m-2 Hz-1 - what about Jy beam-1 (if you are lucky the beam size is given conveniently...?
3. Cone, S?AP, registry searches
   • The current IVOA standards mandate units, but this leads to frequent problems due to to a Cone search/SIAP service returning a region in different units from the one the user thinks they are using (e.g. 0.1 arcmin instead of degree) (see DB queries below).
4. Database queries: We have no control over the units used by data providers (?). We do need to be able to recognise them.
   • Example inspired by Jeff Lusted: What can ADQL do about units for synthetic columns? E.g.

     SELECT a.fint/(a.maj*a."min") 
      as fluxdensity from firstSource as a

     where fint has units of mJy and maj and min have units of arcsec so fluxdensity has units of mJy arcsec-2
   • More complicated cases:
     • In the above case, strictly speaking the divisor should be (a.maj*a.min/4*ln2)

     • SELECT 365.25*a.dist_opt/(a.jdate-2450975.0) 
        as propermotion FROM twomass_psc as a

       where the inputs have units of arcsec and Julian Days (implicit for 2450975.0) but the user wants output in arcsec per year ...
5. Enabling convenient image display with axes labeled in user-specified units/sensible SI multiples.
6. Complex conversions e.g. magnitudes to physical units, are outside our scope but well-defined physical units should make that workpackage easier.
   • 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.
   • Conversion between wavelength and frequency/energy units is non-linear (even without observational issues). Whilst this is trivial (and rounding errors are unimportant) for single simple regions, it makes it hard to describe a spectral resolution of 1 MHz between 1 and 30 GHz, with a single number in wavlength units.

Interactions with other WG efforts

• IVOA VO Query Language

UnitsMir_fichiers

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

IVOA DM Work Package : Units description and usage

• lead Anita Richards

Latest

OldUnitsPage

Main IvoaDataModel page

Goal

Existing Documents

• Standards
  • Standards for Astronomical Catalogues, Version 2.0
  • Type `units' in many types of Linux
  • IAU Recommendations concerning Units from the IAU Style Manual by G.A. Wilkins (1989)
    • Symbols unsuitable for the IVOA as they use Greek letters, diacritical marks etc. which are not easy to use in machine-readable documents; escaped versions could be error-prone. These are not in general used within data (as distinct from free text) anyway.
• Comparison between IAU recommendations, VizieR, HEASARC and the GNU software Units from SebastienDerriere
• Existing VO usage
  • VOSpec model - described in Dimensional Analysis applied to Spectrum Handling in VO context (Osuna & Salgado)
  • Unit strings allowed in STC from ArnoldRots
• CDS has a library for units manipulation. An on-line tool to interpret units is also available (based on recognized symbols). This library has beed used in tools like:
  • MEx, for FITS keyword mapping
  • An homogenized data extraction tool (most suited for VizieR catalogues)
• More:
  • NIST (National Institute of Standards & Technology) project UnitsXML from MarieLiseDubernet
  • FITS FITS references page, development
    • 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)

Recommendations

As discussed at IVOA, Trieste, May 2008

• Goal: to provide suitable tools - Backus Naur form?, libraries and references to allow
  • Recognition of units in use by the members of IVOA
  • Simple (mostly linear) conversions such as metres/parsec; use of SI prefixes (k,M,G eetc.) to avoid bulky numbers or damaged precision.
• Whatever is adopted should as far as possible be compatible with existing VO implimentatations and FITS, and should cover all the relevant IAU types of unit (as distinct from the unsuitable symbols).
  • Please nominate whichever you consider to be the most complete existing system The IVOA should provide translation where there are unambiguous variations in other systems, including from FITS keywords (making use of existing tools/libraries where possible).
• Please identify any serious ambiguities e.g. k could be kilo- or Boltzmann's constant, and suggestions for how to overcome this (recognise by context? Flag for human intervention?).
• Produce web page of links to existing tools for unit handling, conversion, dimensional analysis etc.
  • Example from CDS pages: see Unit conversion link - but in a form which can be linked to user programs or packages in C, IDL, python etc. with simple instructions
• Educate next generation of data providers to use some standard for units!
• Need to record date and reference to values of fundamental quantities where available.
• How far can we go with dimensional analysis? Are there so few cases where it breaks down that these can be handled individually, and if so how does code recognise them (e.g. the Hubble constant, in km/s per Mpc) - or can we specify limited situations where dimensional analysis is adequate?

Use cases

1. TAP - source catalogue DM - need to compare quantities please elaborate
2. 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.
   please elaborate - is this a requirequirement for conversion between physical flux units e.g. mJy, Jy, W m-2 Hz-1 - what about Jy beam-1 (if you are lucky the beam size is given conveniently...?
3. Cone, S?AP, registry searches
   • The current IVOA standards mandate units, but this leads to frequent problems due to to a Cone search/SIAP service returning a region in different units from the one the user thinks they are using (e.g. 0.1 arcmin instead of degree) (see DB queries below).
4. Database queries: We have no control over the units used by data providers (?). We do need to be able to recognise them.
   • Example inspired by Jeff Lusted: What can ADQL do about units for synthetic columns? E.g.

     SELECT a.fint/(a.maj*a."min") 
      as fluxdensity from firstSource as a

     where fint has units of mJy and maj and min have units of arcsec so fluxdensity has units of mJy arcsec-2
   • More complicated cases:
     • In the above case, strictly speaking the divisor should be (a.maj*a.min/4*ln2)

     • SELECT 365.25*a.dist_opt/(a.jdate-2450975.0) 
        as propermotion FROM twomass_psc as a

       where the inputs have units of arcsec and Julian Days (implicit for 2450975.0) but the user wants output in arcsec per year ...
5. Enabling convenient image display with axes labeled in user-specified units/sensible SI multiples.
6. Complex conversions e.g. magnitudes to physical units, are outside our scope but well-defined physical units should make that workpackage easier.
   • 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.
   • Conversion between wavelength and frequency/energy units is non-linear (even without observational issues). Whilst this is trivial (and rounding errors are unimportant) for single simple regions, it makes it hard to describe a spectral resolution of 1 MHz between 1 and 30 GHz, with a single number in wavlength units.

Interactions with other WG efforts

• IVOA VO Query Language

UnitsMir_fichiers

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

IVOA DM Work Package : Units description and usage

• lead Anita Richards

Main IvoaDataModel page

Goal

Existing Documents

• Standards
  • Standards for Astronomical Catalogues, Version 2.0
  • Type `units' in many types of Linux
  • IAU Recommendations concerning Units from the IAU Style Manual by G.A. Wilkins (1989)
    • Symbols unsuitable for the IVOA as they use Greek letters, diacritical marks etc. which are not easy to use in machine-readable documents; escaped versions could be error-prone. These are not in general used within data (as distinct from free text) anyway.
• Comparison between IAU recommendations, VizieR, HEASARC and the GNU software Units from SebastienDerriere
• Existing VO usage
  • VOSpec model - described in Dimensional Analysis applied to Spectrum Handling in VO context (Osuna & Salgado)
  • Unit strings allowed in STC from ArnoldRots
• CDS has a library for units manipulation. An on-line tool to interpret units is also available (based on recognized symbols). This library has beed used in tools like:
  • MEx, for FITS keyword mapping
  • An homogenized data extraction tool (most suited for VizieR catalogues)
• More:
  • NIST (National Institute of Standards & Technology) project UnitsXML from MarieLiseDubernet
  • FITS FITS references page, development
    • 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)

Recommendations

As discussed at IVOA, Trieste, May 2008

• Goal: to provide suitable tools - Backus Naur form?, libraries and references to allow
  • Recognition of units in use by the members of IVOA
  • Simple (mostly linear) conversions such as metres/parsec; use of SI prefixes (k,M,G eetc.) to avoid bulky numbers or damaged precision.
• Whatever is adopted should as far as possible be compatible with existing VO implimentatations and FITS, and should cover all the relevant IAU types of unit (as distinct from the unsuitable symbols).
  • Please nominate whichever you consider to be the most complete existing system The IVOA should provide translation where there are unambiguous variations in other systems, including from FITS keywords (making use of existing tools/libraries where possible).
• Please identify any serious ambiguities e.g. k could be kilo- or Boltzmann's constant, and suggestions for how to overcome this (recognise by context? Flag for human intervention?).
• Produce web page of links to existing tools for unit handling, conversion, dimensional analysis etc.
  • Example from CDS pages: see Unit conversion link - but in a form which can be linked to user programs or packages in C, IDL, python etc. with simple instructions
• Educate next generation of data providers to use some standard for units!
• Need to record date and reference to values of fundamental quantities where available.
• How far can we go with dimensional analysis? Are there so few cases where it breaks down that these can be handled individually, and if so how does code recognise them (e.g. the Hubble constant, in km/s per Mpc) - or can we specify limited situations where dimensional analysis is adequate?

Use cases

1. TAP - source catalogue DM - need to compare quantities please elaborate
2. 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.
   please elaborate - is this a requirequirement for conversion between physical flux units e.g. mJy, Jy, W m-2 Hz-1 - what about Jy beam-1 (if you are lucky the beam size is given conveniently...?
3. Cone, S?AP, registry searches
   • The current IVOA standards mandate units, but this leads to frequent problems due to to a Cone search/SIAP service returning a region in different units from the one the user thinks they are using (e.g. 0.1 arcmin instead of degree) (see DB queries below).
4. Database queries: We have no control over the units used by data providers (?). We do need to be able to recognise them.
   • Example inspired by Jeff Lusted: What can ADQL do about units for synthetic columns? E.g.

     SELECT a.fint/(a.maj*a."min") 
      as fluxdensity from firstSource as a

     where fint has units of mJy and maj and min have units of arcsec so fluxdensity has units of mJy arcsec-2
   • More complicated cases:
     • In the above case, strictly speaking the divisor should be (a.maj*a.min/4*ln2)

     • SELECT 365.25*a.dist_opt/(a.jdate-2450975.0) 
        as propermotion FROM twomass_psc as a

       where the inputs have units of arcsec and Julian Days (implicit for 2450975.0) but the user wants output in arcsec per year ...
5. Enabling convenient image display with axes labeled in user-specified units/sensible SI multiples.
6. Complex conversions e.g. magnitudes to physical units, are outside our scope but well-defined physical units should make that workpackage easier.
   • 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.
   • Conversion between wavelength and frequency/energy units is non-linear (even without observational issues). Whilst this is trivial (and rounding errors are unimportant) for single simple regions, it makes it hard to describe a spectral resolution of 1 MHz between 1 and 30 GHz, with a single number in wavlength units.

Interactions with other WG efforts

• IVOA VO Query Language

UnitsMir_fichiers

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

IVOA DM Work Package : Units description and usage

• lead Anita Richards

Main IvoaDataModel page

Goal

Existing Documents

• Standards
  • Standards for Astronomical Catalogues, Version 2.0
  • Type `units' in many types of Linux
  • IAU Recommendations concerning Units from the IAU Style Manual by G.A. Wilkins (1989)
    • Symbols unsuitable for the IVOA as they use Greek letters, diacritical marks etc. which are not easy to use in machine-readable documents; escaped versions could be error-prone. These are not in general used within data (as distinct from free text) anyway.
• Comparison between IAU recommendations, VizieR, HEASARC and the GNU software Units from SebastienDerriere
• Existing VO usage
  • VOSpec model - described in Dimensional Analysis applied to Spectrum Handling in VO context (Osuna & Salgado)
  • Unit strings allowed in STC from ArnoldRots
• CDS has a library for units manipulation. An on-line tool to interpret units is also available (based on recognized symbols). This library has beed used in tools like:
  • MEx, for FITS keyword mapping
  • An homogenized data extraction tool (most suited for VizieR catalogues)
• More:
  • NIST (National Institute of Standards & Technology) project UnitsXML from MarieLiseDubernet
  • FITS FITS references page, development
    • 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)

Recommendations

As discussed at IVOA, Trieste, May 2008

• Goal: to provide suitable tools - Backus Naur form?, libraries and references to allow
  • Recognition of units in use by the members of IVOA
  • Simple (mostly linear) conversions such as metres/parsec; use of SI prefixes (k,M,G eetc.) to avoid bulky numbers or damaged precision.
• Whatever is adopted should as far as possible be compatible with existing VO implimentatations and FITS, and should cover all the relevant IAU types of unit (as distinct from the unsuitable symbols).
  • Please nominate whichever you consider to be the most complete existing system The IVOA should provide translation where there are unambiguous variations in other systems, including from FITS keywords (making use of existing tools/libraries where possible).
• Please identify any serious ambiguities e.g. k could be kilo- or Boltzmann's constant, and suggestions for how to overcome this (recognise by context? Flag for human intervention?).
• Produce web page of links to existing tools for unit handling, conversion, dimensional analysis etc.
  • Example from CDS pages: see Unit conversion link - but in a form which can be linked to user programs or packages in C, IDL, python etc. with simple instructions
• Educate next generation of data providers to use some standard for units!
• Need to record date and reference to values of fundamental quantities where available.
• How far can we go with dimensional analysis? Are there so few cases where it breaks down that these can be handled individually, and if so how does code recognise them (e.g. the Hubble constant, in km/s per Mpc) - or can we specify limited situations where dimensional analysis is adequate?

Use cases

1. TAP - source catalogue DM - need to compare quantities please elaborate
2. 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.
   please elaborate - is this a requirequirement for conversion between physical flux units e.g. mJy, Jy, W m-2 Hz-1 - what about Jy beam-1 (if you are lucky the beam size is given conveniently...?
3. Cone, S?AP, registry searches
   • The current IVOA standards mandate units, but this leads to frequent problems due to to a Cone search/SIAP service returning a region in different units from the one the user thinks they are using (e.g. 0.1 arcmin instead of degree) (see DB queries below).
4. Database queries: We have no control over the units used by data providers (?). We do need to be able to recognise them.
   • Example inspired by Jeff Lusted: What can ADQL do about units for synthetic columns? E.g.

     SELECT a.fint/(a.maj*a."min") 
      as fluxdensity from firstSource as a

     where fint has units of mJy and maj and min have units of arcsec so fluxdensity has units of mJy arcsec-2
   • More complicated cases:
     • In the above case, strictly speaking the divisor should be (a.maj*a.min/4*ln2)

     • SELECT 365.25*a.dist_opt/(a.jdate-2450975.0) 
        as propermotion FROM twomass_psc as a

       where the inputs have units of arcsec and Julian Days (implicit for 2450975.0) but the user wants output in arcsec per year ...
5. Enabling convenient image display with axes labeled in user-specified units/sensible SI multiples.
6. Complex conversions e.g. magnitudes to physical units, are outside our scope but well-defined physical units should make that workpackage easier.
   • 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.
   • Conversion between wavelength and frequency/energy units is non-linear (even without observational issues). Whilst this is trivial (and rounding errors are unimportant) for single simple regions, it makes it hard to describe a spectral resolution of 1 MHz between 1 and 30 GHz, with a single number in wavlength units.

Interactions with other WG efforts

• IVOA VO Query Language

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

IVOA DM Work Package : Units description and usage

• lead Anita Richards

Draft IVOA working draft

OldUnitsPage

Main IvoaDataModel page

Goal

Existing Documents

• Standards
  • Standards for Astronomical Catalogues, Version 2.0
  • Type `units' in many types of Linux
  • IAU Recommendations concerning Units from the IAU Style Manual by G.A. Wilkins (1989)
    • Symbols unsuitable for the IVOA as they use Greek letters, diacritical marks etc. which are not easy to use in machine-readable documents; escaped versions could be error-prone. These are not in general used within data (as distinct from free text) anyway.
• Comparison between IAU recommendations, VizieR, HEASARC and the GNU software Units from SebastienDerriere
• Existing VO usage
  • VOSpec model - described in Dimensional Analysis applied to Spectrum Handling in VO context (Osuna & Salgado)
  • Unit strings allowed in STC from ArnoldRots
• CDS has a library for units manipulation. An on-line tool to interpret units is also available (based on recognized symbols). This library has beed used in tools like:
  • MEx, for FITS keyword mapping
  • An homogenized data extraction tool (most suited for VizieR catalogues)
• More:
  • NIST (National Institute of Standards & Technology) project UnitsXML from MarieLiseDubernet
  • FITS FITS references page, development
    • 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)

Recommendations

As discussed at IVOA, Trieste, May 2008

• Goal: to provide suitable tools - Backus Naur form?, libraries and references to allow
  • Recognition of units in use by the members of IVOA
  • Simple (mostly linear) conversions such as metres/parsec; use of SI prefixes (k,M,G eetc.) to avoid bulky numbers or damaged precision.
• Whatever is adopted should as far as possible be compatible with existing VO implimentatations and FITS, and should cover all the relevant IAU types of unit (as distinct from the unsuitable symbols).
  • Please nominate whichever you consider to be the most complete existing system The IVOA should provide translation where there are unambiguous variations in other systems, including from FITS keywords (making use of existing tools/libraries where possible).
• Please identify any serious ambiguities e.g. k could be kilo- or Boltzmann's constant, and suggestions for how to overcome this (recognise by context? Flag for human intervention?).
• Produce web page of links to existing tools for unit handling, conversion, dimensional analysis etc.
  • Example from CDS pages: see Unit conversion link - but in a form which can be linked to user programs or packages in C, IDL, python etc. with simple instructions
• Educate next generation of data providers to use some standard for units!
• Need to record date and reference to values of fundamental quantities where available.
• How far can we go with dimensional analysis? Are there so few cases where it breaks down that these can be handled individually, and if so how does code recognise them (e.g. the Hubble constant, in km/s per Mpc) - or can we specify limited situations where dimensional analysis is adequate?

Use cases

1. TAP - source catalogue DM - need to compare quantities please elaborate
2. 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.
   please elaborate - is this a requirequirement for conversion between physical flux units e.g. mJy, Jy, W m-2 Hz-1 - what about Jy beam-1 (if you are lucky the beam size is given conveniently...?
3. Cone, S?AP, registry searches
   • The current IVOA standards mandate units, but this leads to frequent problems due to to a Cone search/SIAP service returning a region in different units from the one the user thinks they are using (e.g. 0.1 arcmin instead of degree) (see DB queries below).
4. Database queries: We have no control over the units used by data providers (?). We do need to be able to recognise them.
   • Example inspired by Jeff Lusted: What can ADQL do about units for synthetic columns? E.g.

     SELECT a.fint/(a.maj*a."min") 
      as fluxdensity from firstSource as a

     where fint has units of mJy and maj and min have units of arcsec so fluxdensity has units of mJy arcsec-2
   • More complicated cases:
     • In the above case, strictly speaking the divisor should be (a.maj*a.min/4*ln2)

     • SELECT 365.25*a.dist_opt/(a.jdate-2450975.0) 
        as propermotion FROM twomass_psc as a

       where the inputs have units of arcsec and Julian Days (implicit for 2450975.0) but the user wants output in arcsec per year ...
5. Enabling convenient image display with axes labeled in user-specified units/sensible SI multiples.
6. Complex conversions e.g. magnitudes to physical units, are outside our scope but well-defined physical units should make that workpackage easier.
   • 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.
   • Conversion between wavelength and frequency/energy units is non-linear (even without observational issues). Whilst this is trivial (and rounding errors are unimportant) for single simple regions, it makes it hard to describe a spectral resolution of 1 MHz between 1 and 30 GHz, with a single number in wavlength units.

Interactions with other WG efforts

• IVOA VO Query Language

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

IVOA DM Work Package : Units description and usage

• lead Anita Richards

Draft IVOA working draft

OldUnitsPage

Main IvoaDataModel page

Goal

Existing Documents

• Standards
  • Standards for Astronomical Catalogues, Version 2.0
  • Type `units' in many types of Linux
  • IAU Recommendations concerning Units from the IAU Style Manual by G.A. Wilkins (1989)
    • Symbols unsuitable for the IVOA as they use Greek letters, diacritical marks etc. which are not easy to use in machine-readable documents; escaped versions could be error-prone. These are not in general used within data (as distinct from free text) anyway.
• Comparison between IAU recommendations, VizieR, HEASARC and the GNU software Units from SebastienDerriere
• Existing VO usage
  • VOSpec model - described in Dimensional Analysis applied to Spectrum Handling in VO context (Osuna & Salgado)
  • Unit strings allowed in STC from ArnoldRots

• More:
  • NIST (National Institute of Standards & Technology) project UnitsXML from MarieLiseDubernet
  • FITS FITS references page, development
    • 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)

Recommendations

As discussed at IVOA, Trieste, May 2008

• Goal: to provide suitable tools - Backus Naur form?, libraries and references to allow
  • Recognition of units in use by the members of IVOA
  • Simple (mostly linear) conversions such as metres/parsec; use of SI prefixes (k,M,G eetc.) to avoid bulky numbers or damaged precision.
• Whatever is adopted should as far as possible be compatible with existing VO implimentatations and FITS, and should cover all the relevant IAU types of unit (as distinct from the unsuitable symbols).
  • Please nominate whichever you consider to be the most complete existing system The IVOA should provide translation where there are unambiguous variations in other systems, including from FITS keywords (making use of existing tools/libraries where possible).
• Please identify any serious ambiguities e.g. k could be kilo- or Boltzmann's constant, and suggestions for how to overcome this (recognise by context? Flag for human intervention?).
• Produce web page of links to existing tools for unit handling, conversion, dimensional analysis etc.
  • Example from CDS pages: see Unit conversion link - but in a form which can be linked to user programs or packages in C, IDL, python etc. with simple instructions
• Educate next generation of data providers to use some standard for units!
• Need to record date and reference to values of fundamental quantities where available.
• How far can we go with dimensional analysis? Are there so few cases where it breaks down that these can be handled individually, and if so how does code recognise them (e.g. the Hubble constant, in km/s per Mpc) - or can we specify limited situations where dimensional analysis is adequate?

Use cases

1. TAP - source catalogue DM - need to compare quantities please elaborate
2. 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.
   please elaborate - is this a requirequirement for conversion between physical flux units e.g. mJy, Jy, W m-2 Hz-1 - what about Jy beam-1 (if you are lucky the beam size is given conveniently...?
3. Cone, S?AP, registry searches
   • The current IVOA standards mandate units, but this leads to frequent problems due to to a Cone search/SIAP service returning a region in different units from the one the user thinks they are using (e.g. 0.1 arcmin instead of degree) (see DB queries below).
4. Database queries: We have no control over the units used by data providers (?). We do need to be able to recognise them.
   • Example inspired by Jeff Lusted: What can ADQL do about units for synthetic columns? E.g.

     SELECT a.fint/(a.maj*a."min") 
      as fluxdensity from firstSource as a

     where fint has units of mJy and maj and min have units of arcsec so fluxdensity has units of mJy arcsec-2
   • More complicated cases:
     • In the above case, strictly speaking the divisor should be (a.maj*a.min/4*ln2)

     • SELECT 365.25*a.dist_opt/(a.jdate-2450975.0) 
        as propermotion FROM twomass_psc as a

       where the inputs have units of arcsec and Julian Days (implicit for 2450975.0) but the user wants output in arcsec per year ...
5. Enabling convenient image display with axes labeled in user-specified units/sensible SI multiples.
6. Complex conversions e.g. magnitudes to physical units, are outside our scope but well-defined physical units should make that workpackage easier.
   • 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.
   • Conversion between wavelength and frequency/energy units is non-linear (even without observational issues). Whilst this is trivial (and rounding errors are unimportant) for single simple regions, it makes it hard to describe a spectral resolution of 1 MHz between 1 and 30 GHz, with a single number in wavlength units.

Interactions with other WG efforts

• IVOA VO Query Language

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

IVOA DM Work Package : Units description and usage

• lead Anita Richards

Draft IVOA working draft

OldUnitsPage

Main IvoaDataModel page

Goal

Existing Documents

• Standards
  • Standards for Astronomical Catalogues, Version 2.0
  • Type `units' in many types of Linux
  • IAU Recommendations concerning Units from the IAU Style Manual by G.A. Wilkins (1989)
    • Symbols unsuitable for the IVOA as they use Greek letters, diacritical marks etc. which are not easy to use in machine-readable documents; escaped versions could be error-prone. These are not in general used within data (as distinct from free text) anyway.
• Comparison between IAU recommendations, VizieR, HEASARC and the GNU software Units from SebastienDerriere
• Existing VO usage
  • VOSpec model - described in Dimensional Analysis applied to Spectrum Handling in VO context (Osuna & Salgado)
  • Unit strings allowed in STC from ArnoldRots
• More:
  • NIST (National Institute of Standards & Technology) project UnitsXML from MarieLiseDubernet
  • FITS FITS references page, development
    • 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)

Recommendations

As discussed at IVOA, Trieste, May 2008

• Goal: to provide suitable tools - Backus Naur form?, libraries and references to allow
  • Recognition of units in use by the members of IVOA
  • Simple (mostly linear) conversions such as metres/parsec; use of SI prefixes (k,M,G eetc.) to avoid bulky numbers or damaged precision.
• Whatever is adopted should as far as possible be compatible with existing VO implimentatations and FITS, and should cover all the relevant IAU types of unit (as distinct from the unsuitable symbols).
  • Please nominate whichever you consider to be the most complete existing system The IVOA should provide translation where there are unambiguous variations in other systems, including from FITS keywords (making use of existing tools/libraries where possible).
• Please identify any serious ambiguities e.g. k could be kilo- or Boltzmann's constant, and suggestions for how to overcome this (recognise by context? Flag for human intervention?).
• Produce web page of links to existing tools for unit handling, conversion, dimensional analysis etc.
  • Example from CDS pages: see Unit conversion link - but in a form which can be linked to user programs or packages in C, IDL, python etc. with simple instructions
• Educate next generation of data providers to use some standard for units!
• Need to record date and reference to values of fundamental quantities where available.
• How far can we go with dimensional analysis? Are there so few cases where it breaks down that these can be handled individually, and if so how does code recognise them (e.g. the Hubble constant, in km/s per Mpc) - or can we specify limited situations where dimensional analysis is adequate?

Use cases

1. TAP - source catalogue DM - need to compare quantities please elaborate
2. 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.
   please elaborate - is this a requirequirement for conversion between physical flux units e.g. mJy, Jy, W m-2 Hz-1 - what about Jy beam-1 (if you are lucky the beam size is given conveniently...?
3. Cone, S?AP, registry searches
   • The current IVOA standards mandate units, but this leads to frequent problems due to to a Cone search/SIAP service returning a region in different units from the one the user thinks they are using (e.g. 0.1 arcmin instead of degree) (see DB queries below).
4. Database queries: We have no control over the units used by data providers (?). We do need to be able to recognise them.
   • Example inspired by Jeff Lusted: What can ADQL do about units for synthetic columns? E.g.

     SELECT a.fint/(a.maj*a."min") 
      as fluxdensity from firstSource as a

     where fint has units of mJy and maj and min have units of arcsec so fluxdensity has units of mJy arcsec-2
   • More complicated cases:
     • In the above case, strictly speaking the divisor should be (a.maj*a.min/4*ln2)

     • SELECT 365.25*a.dist_opt/(a.jdate-2450975.0) 
        as propermotion FROM twomass_psc as a

       where the inputs have units of arcsec and Julian Days (implicit for 2450975.0) but the user wants output in arcsec per year ...
5. Enabling convenient image display with axes labeled in user-specified units/sensible SI multiples.
6. Complex conversions e.g. magnitudes to physical units, are outside our scope but well-defined physical units should make that workpackage easier.
   • 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.
   • Conversion between wavelength and frequency/energy units is non-linear (even without observational issues). Whilst this is trivial (and rounding errors are unimportant) for single simple regions, it makes it hard to describe a spectral resolution of 1 MHz between 1 and 30 GHz, with a single number in wavlength units.

Interactions with other WG efforts

• IVOA VO Query Language

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

IVOA DM Work Package : Units description and usage

• lead Anita Richards

Draft IVOA working draft

OldUnitsPage

Main IvoaDataModel page

Goal

Existing Documents

• Standards
  • Standards for Astronomical Catalogues, Version 2.0
  • Type `units' in many types of Linux
  • IAU Recommendations concerning Units from the IAU Style Manual by G.A. Wilkins (1989)
    • Symbols unsuitable for the IVOA as they use Greek letters, diacritical marks etc. which are not easy to use in machine-readable documents; escaped versions could be error-prone. These are not in general used within data (as distinct from free text) anyway.
• Comparison between IAU recommendations, VizieR, HEASARC and the GNU software Units from SebastienDerriere
• Existing VO usage
  • VOSpec model - described in Dimensional Analysis applied to Spectrum Handling in VO context (Osuna & Salgado)
  • Unit strings allowed in STC from ArnoldRots
• More:
  • NIST (National Institute of Standards & Technology) project UnitsXML from MarieLiseDubernet
  • FITS FITS references page, development
    • 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)

Recommendations

As discussed at IVOA, Trieste, May 2008

• Goal: to provide suitable tools - Backus Naur form?, libraries and references to allow
  • Recognition of units in use by the members of IVOA
  • Simple (mostly linear) conversions such as metres/parsec; use of SI prefixes (k,M,G eetc.) to avoid bulky numbers or damaged precision.
• Whatever is adopted should as far as possible be compatible with existing VO implimentatations and FITS, and should cover all the relevant IAU types of unit (as distinct from the unsuitable symbols).
  • Please nominate whichever you consider to be the most complete existing system The IVOA should provide translation where there are unambiguous variations in other systems, including from FITS keywords (making use of existing tools/libraries where possible).
• Please identify any serious ambiguities e.g. k could be kilo- or Boltzmann's constant, and suggestions for how to overcome this (recognise by context? Flag for human intervention?).
• Produce web page of links to existing tools for unit handling, conversion, dimensional analysis etc.
  • Example from CDS pages: see Unit conversion link - but in a form which can be linked to user programs or packages in C, IDL, python etc. with simple instructions
• Educate next generation of data providers to use some standard for units!
• Need to record date and reference to values of fundamental quantities where available.
• How far can we go with dimensional analysis? Are there so few cases where it breaks down that these can be handled individually, and if so how does code recognise them (e.g. the Hubble constant, in km/s per Mpc) - or can we specify limited situations where dimensional analysis is adequate?

Use cases

1. TAP - source catalogue DM - need to compare quantities please elaborate
2. 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.
   please elaborate - is this a requirequirement for conversion between physical flux units e.g. mJy, Jy, W m-2 Hz-1 - what about Jy beam-1 (if you are lucky the beam size is given conveniently...?
3. Cone, S?AP, registry searches
   • The current IVOA standards mandate units, but this leads to frequent problems due to to a Cone search/SIAP service returning a region in different units from the one the user thinks they are using (e.g. 0.1 arcmin instead of degree) (see DB queries below).
4. Database queries: We have no control over the units used by data providers (?). We do need to be able to recognise them.
   • Example inspired by Jeff Lusted: What can ADQL do about units for synthetic columns? E.g.

     SELECT a.fint/(a.maj*a."min") 
      as fluxdensity from firstSource as a

     where fint has units of mJy and maj and min have units of arcsec so fluxdensity has units of mJy arcsec-2
   • More complicated cases:
     • In the above case, strictly speaking the divisor should be (a.maj*a.min/4*ln2)

     • SELECT 365.25*a.dist_opt/(a.jdate-2450975.0) 
        as propermotion FROM twomass_psc as a

       where the inputs have units of arcsec and Julian Days (implicit for 2450975.0) but the user wants output in arcsec per year ...
5. Enabling convenient image display with axes labeled in user-specified units/sensible SI multiples.
6. Complex conversions e.g. magnitudes to physical units, are outside our scope but well-defined physical units should make that workpackage easier.
   • 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.
   • Conversion between wavelength and frequency/energy units is non-linear (even without observational issues). Whilst this is trivial (and rounding errors are unimportant) for single simple regions, it makes it hard to describe a spectral resolution of 1 MHz between 1 and 30 GHz, with a single number in wavlength units.

Interactions with other WG efforts

• IVOA VO Query Language

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

IVOA DM Work Package : Units description and usage

• lead Anita Richards

Draft IVOA working draft

OldUnitsPage

Main IvoaDataModel page

Goal

Existing Documents

• Standards
  • Standards for Astronomical Catalogues, Version 2.0
  • Type `units' in many types of Linux
  • IAU Recommendations concerning Units from the IAU Style Manual by G.A. Wilkins (1989)
    • Symbols unsuitable for the IVOA as they use Greek letters, diacritical marks etc. which are not easy to use in machine-readable documents; escaped versions could be error-prone. These are not in general used within data (as distinct from free text) anyway.
• Comparison between IAU recommendations, VizieR, HEASARC and the GNU software Units from SebastienDerriere
• Existing VO usage
  • VOSpec model - described in Dimensional Analysis applied to Spectrum Handling in VO context (Osuna & Salgado)
  • Unit strings allowed in STC from ArnoldRots
• More:
  • NIST (National Institute of Standards & Technology) project UnitsXML from MarieLiseDubernet
  • FITS FITS references page, development
    • 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)

Recommendations

As discussed at IVOA, Trieste, May 2008

• Goal: to provide suitable tools - Backus Naur form?, libraries and references to allow
  • Recognition of units in use by the members of IVOA
  • Simple (mostly linear) conversions such as metres/parsec; use of SI prefixes (k,M,G eetc.) to avoid bulky numbers or damaged precision.
• Whatever is adopted should as far as possible be compatible with existing VO implimentatations and FITS, and should cover all the relevant IAU types of unit (as distinct from the unsuitable symbols).
  • Please nominate whichever you consider to be the most complete existing system The IVOA should provide translation where there are unambiguous variations in other systems, including from FITS keywords (making use of existing tools/libraries where possible).
• Please identify any serious ambiguities e.g. k could be kilo- or Boltzmann's constant, and suggestions for how to overcome this (recognise by context? Flag for human intervention?).
• Produce web page of links to existing tools for unit handling, conversion, dimensional analysis etc.
  • Example from CDS pages: see Unit conversion link - but in a form which can be linked to user programs or packages in C, IDL, python etc. with simple instructions
• Educate next generation of data providers to use some standard for units!
• Need to record date and reference to values of fundamental quantities where available.
• How far can we go with dimensional analysis? Are there so few cases where it breaks down that these can be handled individually, and if so how does code recognise them (e.g. the Hubble constant, in km/s per Mpc) - or can we specify limited situations where dimensional analysis is adequate?

Use cases

1. TAP - source catalogue DM - need to compare quantities please elaborate
2. 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.
   please elaborate - is this a requirequirement for conversion between physical flux units e.g. mJy, Jy, W m-2 Hz-1 - what about Jy beam-1 (if you are lucky the beam size is given conveniently...?
3. Cone, S?AP, registry searches
   • The current IVOA standards mandate units, but this leads to frequent problems due to to a Cone search/SIAP service returning a region in different units from the one the user thinks they are using (e.g. 0.1 arcmin instead of degree) (see DB queries below).
4. Database queries: We have no control over the units used by data providers (?). We do need to be able to recognise them.
   • Example inspired by Jeff Lusted: What can ADQL do about units for synthetic columns? E.g.

     SELECT a.fint/(a.maj*a."min") 
      as fluxdensity from firstSource as a

     where fint has units of mJy and maj and min have units of arcsec so fluxdensity has units of mJy arcsec-2
   • More complicated cases:
     • In the above case, strictly speaking the divisor should be (a.maj*a.min/4*ln2)

     • SELECT 365.25*a.dist_opt/(a.jdate-2450975.0) 
        as propermotion FROM twomass_psc as a

       where the inputs have units of arcsec and Julian Days (implicit for 2450975.0) but the user wants output in arcsec per year ...
5. Enabling convenient image display with axes labeled in user-specified units/sensible SI multiples.
6. Complex conversions e.g. magnitudes to physical units, are outside our scope but well-defined physical units should make that workpackage easier.
   • 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.
   • Conversion between wavelength and frequency/energy units is non-linear (even without observational issues). Whilst this is trivial (and rounding errors are unimportant) for single simple regions, it makes it hard to describe a spectral resolution of 1 MHz between 1 and 30 GHz, with a single number in wavlength units.

Interactions with other WG efforts

• IVOA VO Query Language

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

IVOA DM Work Package : Units description and usage

• lead Anita Richards

Draft IVOA working draft

OldUnitsPage

Main IvoaDataModel page

Goal

Existing Documents

• Standards
  • Standards for Astronomical Catalogues, Version 2.0
  • Type `units' in many types of Linux
  • IAU Recommendations concerning Units from the IAU Style Manual by G.A. Wilkins (1989)
    • Symbols unsuitable for the IVOA as they use Greek letters, diacritical marks etc. which are not easy to use in machine-readable documents; escaped versions could be error-prone. These are not in general used within data (as distinct from free text) anyway.
• Comparison between IAU recommendations, VizieR, HEASARC and the GNU software Units from SebastienDerriere
• Existing VO usage
  • VOSpec model - described in Dimensional Analysis applied to Spectrum Handling in VO context (Osuna & Salgado)
  • Unit strings allowed in STC from ArnoldRots
• More:
  • NIST (National Institute of Standards & Technology) project UnitsXML from MarieLiseDubernet
  • FITS FITS references page, development
    • 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)

Recommendations

As discussed at IVOA, Trieste, May 2008

• Goal: to provide suitable tools - Backus Naur form?, libraries and references to allow
  • Recognition of units in use by the members of IVOA
  • Simple (mostly linear) conversions such as metres/parsec; use of SI prefixes (k,M,G eetc.) to avoid bulky numbers or damaged precision.
• Whatever is adopted should as far as possible be compatible with existing VO implimentatations and FITS, and should cover all the relevant IAU types of unit (as distinct from the unsuitable symbols).
  • Please nominate whichever you consider to be the most complete existing system The IVOA should provide translation where there are unambiguous variations in other systems, including from FITS keywords (making use of existing tools/libraries where possible).
• Please identify any serious ambiguities e.g. k could be kilo- or Boltzmann's constant, and suggestions for how to overcome this (recognise by context? Flag for human intervention?).
• Produce web page of links to existing tools for unit handling, conversion, dimensional analysis etc.
  • Example from CDS pages: see Unit conversion link - but in a form which can be linked to user programs or packages in C, IDL, python etc. with simple instructions
• Educate next generation of data providers to use some standard for units!
• Need to record date and reference to values of fundamental quantities where available.
• How far can we go with dimensional analysis? Are there so few cases where it breaks down that these can be handled individually, and if so how does code recognise them (e.g. the Hubble constant, in km/s per Mpc) - or can we specify limited situations where dimensional analysis is adequate?

Use cases

1. TAP - source catalogue DM - need to compare quantities please elaborate
2. 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.
   please elaborate - is this a requirequirement for conversion between physical flux units e.g. mJy, Jy, W m-2 Hz-1 - what about Jy beam-1 (if you are lucky the beam size is given conveniently...?
3. Cone, S?AP, registry searches
   • The current IVOA standards mandate units, but this leads to frequent problems due to to a Cone search/SIAP service returning a region in different units from the one the user thinks they are using (e.g. 0.1 arcmin instead of degree) (see DB queries below).
4. Database queries: We have no control over the units used by data providers (?). We do need to be able to recognise them.
   • Example inspired by Jeff Lusted: What can ADQL do about units for synthetic columns? E.g.

     SELECT a.fint/(a.maj*a."min") 
      as fluxdensity from firstSource as a

     where fint has units of mJy and maj and min have units of arcsec so fluxdensity has units of mJy arcsec-2
   • More complicated cases:
     • In the above case, strictly speaking the divisor should be (a.maj*a.min/4*ln2)

     • SELECT 365.25*a.dist_opt/(a.jdate-2450975.0) 
        as propermotion FROM twomass_psc as a

       where the inputs have units of arcsec and Julian Days (implicit for 2450975.0) but the user wants output in arcsec per year ...
5. Enabling convenient image display with axes labeled in user-specified units/sensible SI multiples.
6. Complex conversions e.g. magnitudes to physical units, are outside our scope but well-defined physical units should make that workpackage easier.
   • 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.
   • Conversion between wavelength and frequency/energy units is non-linear (even without observational issues). Whilst this is trivial (and rounding errors are unimportant) for single simple regions, it makes it hard to describe a spectral resolution of 1 MHz between 1 and 30 GHz, with a single number in wavlength units.

Interactions with other WG efforts

• IVOA VO Query Language

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

IVOA DM Work Package : Units description and usage

• lead Anita Richards

Main IvoaDataModel page

Goal

Existing Documents

• Standards
  • Standards for Astronomical Catalogues, Version 2.0
  • Type `units' in many types of Linux
  • IAU Recommendations concerning Units from the IAU Style Manual by G.A. Wilkins (1989)
    • Symbols unsuitable for the IVOA as they use Greek letters, diacritical marks etc. which are not easy to use in machine-readable documents; escaped versions could be error-prone. These are not in general used within data (as distinct from free text) anyway.
• Comparison between IAU recommendations, VizieR, HEASARC and the GNU software Units from SebastienDerriere
• Existing VO usage
  • VOSpec model - described in Dimensional Analysis applied to Spectrum Handling in VO context (Osuna & Salgado)
  • Unit strings allowed in STC from ArnoldRots
• More:
  • NIST (National Institute of Standards & Technology) project UnitsXML from MarieLiseDubernet
  • FITS FITS references page, development
    • 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)

Recommendations

As discussed at IVOA, Trieste, May 2008

• Goal: to provide suitable tools - Backus Naur form?, libraries and references to allow
  • Recognition of units in use by the members of IVOA
  • Simple (mostly linear) conversions such as metres/parsec; use of SI prefixes (k,M,G eetc.) to avoid bulky numbers or damaged precision.
• Whatever is adopted should as far as possible be compatible with existing VO implimentatations and FITS, and should cover all the relevant IAU types of unit (as distinct from the unsuitable symbols).
  • Please nominate whichever you consider to be the most complete existing system The IVOA should provide translation where there are unambiguous variations in other systems, including from FITS keywords (making use of existing tools/libraries where possible).
• Please identify any serious ambiguities e.g. k could be kilo- or Boltzmann's constant, and suggestions for how to overcome this (recognise by context? Flag for human intervention?).
• Produce web page of links to existing tools for unit handling, conversion, dimensional analysis etc.
  • Example from CDS pages: see Unit conversion link - but in a form which can be linked to user programs or packages in C, IDL, python etc. with simple instructions
• Educate next generation of data providers to use some standard for units!
• Need to record date and reference to values of fundamental quantities where available.
• How far can we go with dimensional analysis? Are there so few cases where it breaks down that these can be handled individually, and if so how does code recognise them (e.g. the Hubble constant, in km/s per Mpc) - or can we specify limited situations where dimensional analysis is adequate?

Use cases

1. TAP - source catalogue DM - need to compare quantities please elaborate
2. 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.
   please elaborate - is this a requirequirement for conversion between physical flux units e.g. mJy, Jy, W m-2 Hz-1 - what about Jy beam-1 (if you are lucky the beam size is given conveniently...?
3. Cone, S?AP, registry searches
   • The current IVOA standards mandate units, but this leads to frequent problems due to to a Cone search/SIAP service returning a region in different units from the one the user thinks they are using (e.g. 0.1 arcmin instead of degree) (see DB queries below).
4. Database queries: We have no control over the units used by data providers (?). We do need to be able to recognise them.
   • Example inspired by Jeff Lusted: What can ADQL do about units for synthetic columns? E.g.

     SELECT a.fint/(a.maj*a."min") 
      as fluxdensity from firstSource as a

     where fint has units of mJy and maj and min have units of arcsec so fluxdensity has units of mJy arcsec-2
   • More complicated cases:
     • In the above case, strictly speaking the divisor should be (a.maj*a.min/4*ln2)

     • SELECT 365.25*a.dist_opt/(a.jdate-2450975.0) 
        as propermotion FROM twomass_psc as a

       where the inputs have units of arcsec and Julian Days (implicit for 2450975.0) but the user wants output in arcsec per year ...
5. Enabling convenient image display with axes labeled in user-specified units/sensible SI multiples.
6. Complex conversions e.g. magnitudes to physical units, are outside our scope but well-defined physical units should make that workpackage easier.
   • 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.
   • Conversion between wavelength and frequency/energy units is non-linear (even without observational issues). Whilst this is trivial (and rounding errors are unimportant) for single simple regions, it makes it hard to describe a spectral resolution of 1 MHz between 1 and 30 GHz, with a single number in wavlength units.

Interactions with other WG efforts

• IVOA VO Query Language

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

IVOA DM Work Package : Units description and usage

OldUnitsPage

Main IvoaDataModel page

Goal

Existing Documents

• Standards
  • Standards for Astronomical Catalogues, Version 2.0
  • Type `units' in many types of Linux
  • IAU Recommendations concerning Units from the IAU Style Manual by G.A. Wilkins (1989)
    • Symbols unsuitable for the IVOA as they use Greek letters, diacritical marks etc. which are not easy to use in machine-readable documents; escaped versions could be error-prone. These are not in general used within data (as distinct from free text) anyway.
• Comparison between IAU recommendations, VizieR, HEASARC and the GNU software Units from SebastienDerriere
• Existing VO usage
  • VOSpec model - described in Dimensional Analysis applied to Spectrum Handling in VO context (Osuna & Salgado)
  • Unit strings allowed in STC from ArnoldRots
• More:
  • NIST (National Institute of Standards & Technology) project UnitsXML from MarieLiseDubernet
  • FITS FITS references page, development
    • 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)

Recommendations

As discussed at IVOA, Trieste, May 2008

• Goal: to provide suitable tools - Backus Naur form?, libraries and references to allow
  • Recognition of units in use by the members of IVOA
  • Simple (mostly linear) conversions such as metres/parsec; use of SI prefixes (k,M,G eetc.) to avoid bulky numbers or damaged precision.
• Whatever is adopted should as far as possible be compatible with existing VO implimentatations and FITS, and should cover all the relevant IAU types of unit (as distinct from the unsuitable symbols).
  • Please nominate whichever you consider to be the most complete existing system The IVOA should provide translation where there are unambiguous variations in other systems, including from FITS keywords (making use of existing tools/libraries where possible).
• Please identify any serious ambiguities e.g. k could be kilo- or Boltzmann's constant, and suggestions for how to overcome this (recognise by context? Flag for human intervention?).
• Produce web page of links to existing tools for unit handling, conversion, dimensional analysis etc.
  • Example from CDS pages: see Unit conversion link - but in a form which can be linked to user programs or packages in C, IDL, python etc. with simple instructions
• Educate next generation of data providers to use some standard for units!
• Need to record date and reference to values of fundamental quantities where available.
• How far can we go with dimensional analysis? Are there so few cases where it breaks down that these can be handled individually, and if so how does code recognise them (e.g. the Hubble constant, in km/s per Mpc) - or can we specify limited situations where dimensional analysis is adequate?

Use cases

1. TAP - source catalogue DM - need to compare quantities please elaborate
2. 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.
   please elaborate - is this a requirequirement for conversion between physical flux units e.g. mJy, Jy, W m-2 Hz-1 - what about Jy beam-1 (if you are lucky the beam size is given conveniently...?
3. Cone, S?AP, registry searches
   • The current IVOA standards mandate units, but this leads to frequent problems due to to a Cone search/SIAP service returning a region in different units from the one the user thinks they are using (e.g. 0.1 arcmin instead of degree) (see DB queries below).
4. Database queries: We have no control over the units used by data providers (?). We do need to be able to recognise them.
   • Example inspired by Jeff Lusted: What can ADQL do about units for synthetic columns? E.g.

     SELECT a.fint/(a.maj*a."min") 
      as fluxdensity from firstSource as a

     where fint has units of mJy and maj and min have units of arcsec so fluxdensity has units of mJy arcsec-2
   • More complicated cases:
     • In the above case, strictly speaking the divisor should be (a.maj*a.min/4*ln2)

     • SELECT 365.25*a.dist_opt/(a.jdate-2450975.0) 
        as propermotion FROM twomass_psc as a

       where the inputs have units of arcsec and Julian Days (implicit for 2450975.0) but the user wants output in arcsec per year ...
5. Enabling convenient image display with axes labeled in user-specified units/sensible SI multiples.
6. Complex conversions e.g. magnitudes to physical units, are outside our scope but well-defined physical units should make that workpackage easier.
   • 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.
   • Conversion between wavelength and frequency/energy units is non-linear (even without observational issues). Whilst this is trivial (and rounding errors are unimportant) for single simple regions, it makes it hard to describe a spectral resolution of 1 MHz between 1 and 30 GHz, with a single number in wavlength units.

Interactions with other WG efforts

• IVOA VO Query Language

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

IVOA DM Work Package : Units description and usage

• lead Anita Richards with help from MireilleLouys

OldUnitsPage

Goal

Existing Documents

• Standards
  • Standards for Astronomical Catalogues, Version 2.0
  • Type `units' in many types of Linux
  • IAU Recommendations concerning Units from the IAU Style Manual by G.A. Wilkins (1989)
    • Symbols unsuitable for the IVOA as they use Greek letters, diacritical marks etc. which are not easy to use in machine-readable documents; escaped versions could be error-prone. These are not in general used within data (as distinct from free text) anyway.
• Comparison between IAU recommendations, VizieR, HEASARC and the GNU software Units from SebastienDerriere
• Existing VO usage
  • VOSpec model - described in Dimensional Analysis applied to Spectrum Handling in VO context (Osuna & Salgado)
  • Unit strings allowed in STC from ArnoldRots
• More:
  • NIST (National Institute of Standards & Technology) project UnitsXML from MarieLiseDubernet
  • FITS FITS references page, development
    • 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)

Recommendations

As discussed at IVOA, Trieste, May 2008

• • Recognition of units in use by the members of IVOA
  • Simple (mostly linear) conversions such as metres/parsec; use of SI prefixes (k,M,G eetc.) to avoid bulky numbers or damaged precision.
• Whatever is adopted should as far as possible be compatible with existing VO implimentatations and FITS, and should cover all the relevant IAU types of unit (as distinct from the unsuitable symbols).
  • Please nominate whichever you consider to be the most complete existing system The IVOA should provide translation where there are unambiguous variations in other systems, including from FITS keywords (making use of existing tools/libraries where possible).
• Please identify any serious ambiguities e.g. k could be kilo- or Boltzmann's constant, and suggestions for how to overcome this (recognise by context? Flag for human intervention?).
• Produce web page of links to existing tools for unit handling, conversion, dimensional analysis etc.
  • Example from CDS pages: see Unit conversion link - but in a form which can be linked to user programs or packages in C, IDL, python etc. with simple instructions
• Educate next generation of data providers to use some standard for units!
• Need to record date and reference to values of fundamental quantities where available.
• How far can we go with dimensional analysis? Are there so few cases where it breaks down that these can be handled individually, and if so how does code recognise them (e.g. the Hubble constant, in km/s per Mpc) - or can we specify limited situations where dimensional analysis is adequate?

Use cases

1. TAP - source catalogue DM - need to compare quantities please elaborate
2. 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.
   please elaborate - is this a requirequirement for conversion between physical flux units e.g. mJy, Jy, W m-2 Hz-1 - what about Jy beam-1 (if you are lucky the beam size is given conveniently...?
3. Cone, S?AP, registry searches
   • The current IVOA standards mandate units, but this leads to frequent problems due to to a Cone search/SIAP service returning a region in different units from the one the user thinks they are using (e.g. 0.1 arcmin instead of degree) (see DB queries below).
4. Database queries: We have no control over the units used by data providers (?). We do need to be able to recognise them.
   • Example inspired by Jeff Lusted: What can ADQL do about units for synthetic columns? E.g.

     SELECT a.fint/(a.maj*a."min") 
      as fluxdensity from firstSource as a

     where fint has units of mJy and maj and min have units of arcsec so fluxdensity has units of mJy arcsec-2
   • More complicated cases:
     • In the above case, strictly speaking the divisor should be (a.maj*a.min/4*ln2)

     • SELECT 365.25*a.dist_opt/(a.jdate-2450975.0) 
        as propermotion FROM twomass_psc as a

       where the inputs have units of arcsec and Julian Days (implicit for 2450975.0) but the user wants output in arcsec per year ...
5. Enabling convenient image display with axes labeled in user-specified units/sensible SI multiples.
6. Complex conversions e.g. magnitudes to physical units, are outside our scope but well-defined physical units should make that workpackage easier.
   • 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.
   • Conversion between wavelength and frequency/energy units is non-linear (even without observational issues). Whilst this is trivial (and rounding errors are unimportant) for single simple regions, it makes it hard to describe a spectral resolution of 1 MHz between 1 and 30 GHz, with a single number in wavlength units.

Interactions with other WG efforts

• IVOA VO Query Language

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

IVOA DM Work Package : Units description and usage

• lead Anita Richards with help from MireilleLouys

OldUnitsPage

Main IvoaDataModel page

Goal

Existing Documents

• Standards
  • Standards for Astronomical Catalogues, Version 2.0
  • Type `units' in many types of Linux
  • IAU Recommendations concerning Units from the IAU Style Manual by G.A. Wilkins (1989)
    • Symbols unsuitable for the IVOA as they use Greek letters, diacritical marks etc. which are not easy to use in machine-readable documents; escaped versions could be error-prone. These are not in general used within data (as distinct from free text) anyway.
• Comparison between IAU recommendations, VizieR, HEASARC and the GNU software Units from SebastienDerriere
• Existing VO usage
  • VOSpec model - described in Dimensional Analysis applied to Spectrum Handling in VO context (Osuna & Salgado)
  • Unit strings allowed in STC from ArnoldRots
• More:
  • NIST (National Institute of Standards & Technology) project UnitsXML from MarieLiseDubernet
  • FITS FITS references page, development
    • 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)

Recommendations

As discussed at IVOA, Trieste, May 2008

• Goal: to provide schemata and libraries and references to allow
  • Recognition of units in use by the members of IVOA
  • Simple (mostly linear) conversions such as metres/parsec; use of SI prefixes (k,M,G eetc.) to avoid bulky numbers or damaged precision.
• Whatever is adopted should as far as possible be compatible with existing VO implimentatations and FITS, and should cover all the relevant IAU types of unit (as distinct from the unsuitable symbols).
  • Please nominate whichever you consider to be the most complete existing system The IVOA should provide translation where there are unambiguous variations in other systems, including from FITS keywords (making use of existing tools/libraries where possible).

• Produce web page of links to existing tools for unit handling, conversion, dimensional analysis etc.
  • Example from CDS pages: see Unit conversion link - but in a form which can be linked to user programs or packages in C, IDL, python etc. with simple instructions
• Educate next generation of data providers to use some standard for units!
• Need to record date and reference to values of fundamental quantities where available.

Use cases

• • 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.
  • Conversion between wavelength and frequency/energy units is non-linear (even without observational issues). Whilst this is trivial (and rounding errors are unimportant) for single simple regions, it makes it hard to describe a spectral resolution of 1 MHz between 1 and 30 GHz, with a single number in wavlength units.

Interactions with other WG efforts

• IVOA VO Query Language

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

IVOA DM Work Package : Units description and usage

• lead Anita Richards with help from MireilleLouys

OldUnitsPage

Goal

Existing Documents

• Standards
  • Standards for Astronomical Catalogues, Version 2.0
  • Type `units' in many types of Linux
  • IAU Recommendations concerning Units from the IAU Style Manual by G.A. Wilkins (1989)
    • Symbols unsuitable for the IVOA as they use Greek letters, diacritical marks etc. which are not easy to use in machine-readable documents; escaped versions could be error-prone. These are not in general used within data (as distinct from free text) anyway.
• Comparison between IAU recommendations, VizieR, HEASARC and the GNU software Units from SebastienDerriere
• Existing VO usage
  • VOSpec model - described in Dimensional Analysis applied to Spectrum Handling in VO context (Osuna & Salgado)
  • Unit strings allowed in STC from ArnoldRots
• More:
  • NIST (National Institute of Standards & Technology) project UnitsXML from MarieLiseDubernet
  • FITS FITS references page, development
    • 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)

Recommendations

As discussed at IVOA, Trieste, May 2008

• Goal: to provide schemata and libraries and references to allow
  • Recognition of units in use by the members of IVOA
  • Simple (mostly linear) conversions such as metres/parsec; use of SI prefixes (k,M,G eetc.) to avoid bulky numbers or damaged precision.
• Whatever is adopted should as far as possible be compatible with existing VO implimentatations and FITS, and should cover all the relevant IAU types of unit (as distinct from the unsuitable symbols).
  • Please nominate whichever you consider to be the most complete existing system The IVOA should provide translation where there are unambiguous variations in other systems, including from FITS keywords (making use of existing tools/libraries where possible).
• *Please identify any serious ambiguities e.g. k could be kilo- or Boltzmann's constant, and suggestions for how to overcome this (recognise by context? Flag for human intervention?).
• Produce web page of links to existing tools for unit handling, conversion, dimensional analysis etc.
  • Example from CDS pages: see Unit conversion link - but in a form which can be linked to user programs or packages in C, IDL, python etc. with simple instructions
• Educate next generation of data providers to use some standard for units!
• Need to record date and reference to values of fundamental quantities where available.

Use cases

• Complex conversions e.g. magnitudes to physical units, are outside our scope but well-defined physical units should make that workpackage easier.
  • 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.
  • Conversion between wavelength and frequency/energy units is non-linear (even without observational issues). Whilst this is trivial (and rounding errors are unimportant) for single simple regions, it makes it hard to describe a spectral resolution of 1 MHz between 1 and 30 GHz, with a single number in wavlength units.
• 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.
  

• Cone, S?AP, registry searches
  • The current IVOA standards mandate units, but in some cases this repeatedly leads to problems e.g..
    • Anomalous results are often obtained due to a Cone search/SIAP service returning a region in different units from the one the user thinks they are using (e.g. 0.1 arcmin instead of degree) (see DB queries below).
• Database queries: We have no control over the units used by data providers (?). We do need to be able to recognise them.
• Enabling convenient image display with axes labeled in user-specified units/sensible SI multiples.

Interactions with other WG efforts

• IVOA VO Query Language

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

IVOA DM Work Package : Units description and usage

• lead Anita Richards with help from MireilleLouys

Goal

Existing Documents

• Standards
  • Standards for Astronomical Catalogues, Version 2.0

• • Type `units' in many types of Linux

• • VOSpec model - described in Dimensional Analysis applied to Spectrum Handling in VO context (Osuna & Salgado)

• • Unit strings allowed in STC from ArnoldRots

Interactions with other WG efforts

• IVOA VO Query Language

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

IVOA DM Work Package : Units description and usage

• lead Anita Richards with help from MireilleLouys

Goal

Recommendations

From IVOA Trieste 2008 May 19.

• Produce list of IVOA-supported units
  • Preferred (e.g. CDS and HEASARC)
    • Is HEASARC the same as STC? If not, STC also
  • Acceptable (where other strings exist)
    • AMSR comment a few alternatives would be acceptable e.g. au or AU for Astronomical Unit, where these are unambigous; we have to be able to cater for existing data.
• Produce web page of links to existing tools for unit handling, conversion, dimensional analysis etc.

• • Complex conversions e.g. magnitudes to physical units, are outside our scope but well-defined physical units should make that workpackage easier.
• Educate next generation of data providers to use some standard for units
• Outstanding issues
  • FITS units and other systems - can these all be handled by assuming that the IVOA provides access to such data via a metadata database? in which case the software which populates the DB (e.g. MEXX) does the translating from FITS standards or even known non-standards?
  • Need to record date and reference to values of fundamental quantities where available.
• Identified key players (please add yourself as appropriate)
  • ESAC - dimensional analysis
  • AstroGrid - STILTS and Starlink libraries
  • STC team - someone working on units

Previous discussion/links to existing libraries of units

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

Action: There are few instances of multiple legitimate names for the same unit (benign). There may be a very few instances of the same name for different units e.g. k could be kilo- or Boltzmann's constant, but this could be solved by adopting a syntax for separating prefixes v. different components of multiple units. IVOA units must be machine readable which makes parts of the IAU system unsuitable since they use Greek letters, diacritical marks etc. However it seems to me that a schema could be written which combined CDS and HEASARC and STC as unambigious alternatives and this would be much quicker than trying to modify existing data.

We should make sure that tools for extracting metadata from FITS is consistent with this (is there a need for transation from FITS keywords). This is the point where custom exensions to software could correctly interpret errors like the infamous ISO Watts.

• NB need to specify (where possible) the date and reference for values used when data were published e.g. value of second, metre.

Existing or new tools and Libraries

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

Need precise unit definitions

Examples include:

• 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

We have no control over the units used by data providers (?). We do need to be able to recognise them.

• 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?

Actually we can have influence - e.g. through Euro-VO DCA - at least to remind people to adhere to appropriate 'local' standard e.g.

• no plurals W or Watt but never Watts (ambiguity with Watt second)
• capitalisation matters m(illi) v. M(ega)

Enabling convenient image display

Use case: Need a library to support displaying images with coordinates in sensible units (i.e. using SI multiple etc.) and to allow easy conversions e.g. Jy arcsec-2 to Jy sr-1 (JP Leahy).

Lessons so far

Dimensional approach (see VOSpec)

Automated dimensional analysis could be an easy way to check for consistency. Request for dimensional analysis tools/library to be available.

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
 
 
-->

IVOA DM Work Package : Units description and usage

• lead Anita Richards with help from MireilleLouys

Goal

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

Action: There are few instances of multiple legitimate names for the same unit (benign). There may be a very few instances of the same name for different units e.g. k could be kilo- or Boltzmann's constant, but this could be solved by adopting a syntax for separating prefixes v. different components of multiple units. IVOA units must be machine readable which makes parts of the IAU system unsuitable since they use Greek letters, diacritical marks etc. However it seems to me that a schema could be written which combined CDS and HEASARC and STC as unambigious alternatives and this would be much quicker than trying to modify existing data.

We should make sure that tools for extracting metadata from FITS is consistent with this (is there a need for transation from FITS keywords). This is the point where custom exensions to software could correctly interpret errors like the infamous ISO Watts.

Existing or new tools and Libraries

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

Need precise unit definitions

Examples include:

• 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

We have no control over the units used by data providers (?). We do need to be able to recognise them.

• 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?

Actually we can have influence - e.g. through Euro-VO DCA - at least to remind people to adhere to appropriate 'local' standard e.g.

• no plurals W or Watt but never Watts (ambiguity with Watt second)
• capitalisation matters m(illi) v. M(ega)

Enabling convenient image display

Use case: Need a library to support displaying images with coordinates in sensible units (i.e. using SI multiple etc.) and to allow easy conversions e.g. Jy arcsec-2 to Jy sr-1 (JP Leahy).

Lessons so far

Dimensional approach (see VOSpec)

Automated dimensional analysis could be an easy way to check for consistency. Request for dimensional analysis tools/library to be available.

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
 
 
-->

IVOA DM Work Package : Units description and usage

• lead Anita Richards with help from MireilleLouys

Goal

Updated IVOA Trieste 2008 May 19.

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

Existing or new tools and Libraries

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

Need precise unit definitions

Examples include:

• 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

We have no control over the units used by data providers (?). We do need to be able to recognise them.

• 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?

Actually we can have influence - e.g. through Euro-VO DCA - at least to remind people to adhere to appropriate 'local' standard e.g.

• no plurals W or Watt but never Watts (ambiguity with Watt second)
• capitalisation matters m(illi) v. M(ega)

Enabling convenient image display

Use case: Need a library to support displaying images with coordinates in sensible units (i.e. using SI multiple etc.) and to allow easy conversions e.g. Jy arcsec-2 to Jy sr-1 (JP Leahy).

Lessons so far

Dimensional approach (see VOSpec)

Automated dimensional analysis could be an easy way to check for consistency. Request for dimensional analysis tools/library to be available.

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
 
 
-->

IVOA DM Work Package : Units description and usage

• lead Anita Richards with help from MireilleLouys

Goal

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

Existing or new tools and Libraries

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

Need precise unit definitions

Examples include:

• 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

We have no control over the units used by data providers (?). We do need to be able to recognise them.

• 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?

Actually we can have influence - e.g. through Euro-VO DCA - at least to remind people to adhere to appropriate 'local' standard e.g.

• no plurals W or Watt but never Watts (ambiguity with Watt second)
• capitalisation matters m(illi) v. M(ega)

Enabling convenient image display

Use case: Need a library to support displaying images with coordinates in sensible units (i.e. using SI multiple etc.) and to allow easy conversions e.g. Jy arcsec-2 to Jy sr-1 (JP Leahy).

Lessons so far

Dimensional approach (see VOSpec)

Automated dimensional analysis could be an easy way to check for consistency. Request for dimensional analysis tools/library to be available.

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
 
 
-->

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
 
 
-->

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

Examples include:

• 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

We have no control over the units used by data providers. We do need to be able to recognise them.

• 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)

Automated dimensional analysis could be an easy way to check for consistency

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
 
 
-->

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.

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

Examples include:

• 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

We have no control over the units used by data providers. We do need to be able to recognise them.

• 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)

Automated dimensional analysis could be an easy way to check for consistency

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
 
 
-->

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

• • 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...

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

Examples include:

• 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

We have no control over the units used by data providers. We do need to be able to recognise them.

• 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)

Automated dimensional analysis could be an easy way to check for consistency

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

Requirements from other groups

• in
• out
• ...

Conclusions

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

• minutes_units_discussion_070927.txt: Minutes of initial discussion: Cambridge, 20070927

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/implimentation
  • 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)

• • check SpecView...

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

Examples include:

• 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

We have no control over the units used by data providers. We do need to be able to recognise them.

• 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)

Automated dimensional analysis could be an easy way to check for consistency

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

Requirements from other groups

• in
• out
• ...

Conclusions

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

• minutes_units_discussion_070927.txt: Minutes of initial discussion: Cambridge, 20070927

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/implimentation
  • 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

Where are units needed?