Timesys note review

[AdaNebot]

Hi, 

> 
>> TOPOCENTER
>>   +------- EARTH_SURFACE
>>   |             +-------------- LA_SILLA
>>   |             +-------------- MAUNA_KEA
>>   |             `-------------- CAMBRIDGE_UK
>>   +------- LEO
>>   |         +------------ ISS
>>   |         `------------ ROSAT
>>   `------- EARTH_L2
>>                +------------ GAIA
>>                `------------ JWST
>> 
>> and so on.  If a client happens to know MAUNA_KEA, it can use a proper
>> transformation.  If not, it can *from the vocabulary* (i.e., from a
>> resource maintained by "us") figure out that it's EARTH_SURFACE and that
>> it therefore has to bump the systematic error by 25 ms.  If it
>> doesn't know about EARTH_SURFACE, it can still figure out that the
>> times are TOPOCENTER and that it should be careful.
> 
> That looks neat.

I like the idea. 
What do we do with missions on their way somewhere (Cassini, Voyager,…) ? 

> 
> So then the examples in the document would become
> 
>   <TIMESYS ID="gaia_frame" refposition="BARYCENTER" timeorigin="JD"
>            timescale="TCB"/>
> 
> and
> 
>   <TIMESYS refposition="TOPOCENTER" timescale="TT" timeorigin="MJD"
>            ID="_MJD"/>
> 
> while e.g. the Gaia epoch photometry available from
> http://geadata.esac.esa.int/data-server/data?RETRIEVAL_TYPE=epoch_photometry
> could write:
> 
>   <TIMESYS refposition="BARYCENTER" timescale="TCB" timeorigin="2455197.5"
>            ID="whatever"/>
> 
> And probably a large proportion of real life usages would look like
> one of the first two examples above and not like the third one.
> 

I  think lots of cases will be like the last one. 

My two cents right now,
Ada



> Somewhat related: I think the discussion of the timeorigin attribute
> in section 2 should be tightened up a little bit, so it's clear that
> a value MUST be present for non-year-like time values as well as
> saying that it MUST NOT be present for calendar-year-like values.
> 
> So, I'd suggest something like:
> 
>   \item[\xmlel{timeorigin}] This is the time origin of the time coordinate,
>   which MUST be present when the time value being annotated represents
>   an interval elapsed from an origin, such as MJD.
>   When present, the timeorigin represents a Julian Date for the time scale
>   and reference point defined, and is given
>   {\em either\/}
>   as a floating point value formatted as for type \xmlel{xs:double},
>   {\em or\/}
>   as one of the special tokens "JD" (equivalent to "0")
>   or "MJD" (equivalent to "2400000.5").
>   If the time value being annotated represents an absolute date,
>   this attribute MUST NOT be present.
>   In VOTables, absolute date representations
>   currently are Gregorian calendar years with
>   xtype="timestamp", or values with units of "yr", "a" or "Ba"
>   understood to be in the Julian or Besselian calendar.\footnote{
>   When using calendar epochs written in yr or Ba, note
>   that conventionally Julian years are tied to the TDB timescale and
>   Besselian years to ET (written here as TT)
>   \citep{2015A&A...574A..36R}.}
>   Future
>   VOTable or VOUnits versions may define other such absolute date
>   representations.
> 
> ... but no objection to rewriting it for reasons of correctness,
> clarity or style.
> 
> Mark
> 
> --
> Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/