VOunits draft

Rob Seaman seaman at noao.edu
Tue May 26 20:15:05 PDT 2009

```Hi Alberto,

> 1.- What's wrong with saying that 1 Mpc is just 3.08568025E+22 meters?

As Steve Allen pointed out:

>> Consider the issue of AU vs. m
>> AU is not SI.  m is SI, but beware
>>
>> 1 AU = 149597870691 m in TDB/TT units ("not SI" units according to
>> IAU comm 52)
>> 1 AU = 149597870795 m in TCG units (IAU recommended for vicinity of
>> earth)
>> 1 AU = 149597873011 m in TCG units (IAU recommended for solar system)
>>
>> Every application I know currently uses the "not SI" TDB/TT units.

The parsec is directly related to the astronomical unit (1 parsec =
180*60*60/pi AU), so this issue applies to Mpc as well.

> Still, to be exact, the VO could declare that
> - the original representation was in Mpc
> - the precision stopped at the integral part of the Mpc.
> - a VO distance is always internally expressed in meters,
> - the VO conversion factor for (e.g.) Mpc is 3.0whateverE+16.)

That makes several new pieces of metadata just to preserve the
original representation.

> 2.- Why do we need Zettameters? Why do we need SI prefixes?
>
> Is the E+22 formulation too simple and general to be acceptable?

I'm getting more confused about what is being suggested.  Are we just
talking about the mantissa and exponent of floating point numbers?  Or
is the suggestion that we have an explicit string representation for
scientific notation?

In general it seems like this discussion has devolved into haggling
about details of a proposed solution, when the requirements describing
the problem space have yet to fully discovered.  I actually find yotta
and yocto, zetta and zepto as charming as the Marx brothers they
resemble.  Is "charming" a requirement on the VO?

While folks are discussing prefixes, note that centi, deci, deka and
hecto are irregular and limited to certain cases, the centimeter being
the most familiar.  The other cases are apparently areas (hectare =
sq. hm) and volumes.

> 3.- It is up to the user to ultimately decide which units are
> relevant to him.

VOEvent simply needs a method for accurately tagging the units as
provided by event authors.  Perhaps this standard doesn't pertain to
semantic usage as required by VOEvent?

> PS: I'm not forgetting the fact that all servers will probably have
> to perform a conversion from the originally stored unit to the VO
> standard one, but given that my client will have to wait for the
> various streams coming from those different servers, that little
> overhead introduced by the conversion will have less impact overall.

Perhaps the VOEvent brokers/clients sit outside the system
encompassing the standard?

Rob

```