TimeSeries of position (Asteroid)

[Dave Morris]

Hi Arnold,

Thank you for your input on this.

François was working from a very sketchy straw-man proposal from me, 
looking for areas that the data modelling work on time-series might not 
have covered yet.

Even if the initial set of data models for time-series don't include 
everything needed to cover every use cases, we would like to make sure 
that we don't inadvertently add something to the models now that 
prevents them from being extended to cover more detailed use cases 
later.

Could you provide us with a few annotated examples of the FITS file 
headers, or some documentation on current best practice, so that we can 
include these in our work on time-series.

Also, daft question (I'm an engineer not an astronomer), is there a 
stage before the state vectors have been calculated? Where an astronomer 
just has a series of times and positions and would want to store, 
process or share these with other researchers? If so, would the metadata 
in the headers be different?

Many thanks,
-- Dave

--------
Dave Morris
Research Software Engineer
Wide Field Astronomy Unit
Institute for Astronomy
University of Edinburgh
--------


On 2018-11-23 20:53, Arnold Rots wrote:
> ...  also known as an ephemeris.
> 
> We use a standard FITS file format for orbit and solar system body
> ephemerides, with 7 columns - time and state vector:
> Time (TT), X, Y, Z, Vx, Vy, Vz
> The state vector is in ITRS, its units m and m/s. All at GEOCENTER.
> The solar system body ephemerides are derived from an ephemeris format 
> that
> contains:
> Time (TDB), Xs, Ys, Zs, Xe, Ye, Ze
> The position vector for earth (e) and SS object (s) are in ICRS at 
> origin
> BARYCENTER, their units AU.
> 
> The three points I want to make are:
> 
> 1. 3-D Cartesian coordinates are preferable, since you are working in 
> the
> near field
> ICRS RA and Dec at BARYCENTER, without a solar distance, are useless 
> for
> conversion to some specific location
> 
> 2. State vectors (i.e., adding the spatial time derivatives) are 
> extremely
> helpful, especially for fast-moving objects
> 
> 3. There is one ambiguity that is not addressed here:
> If you provide time T and location S of an object with a common 
> coordinate
> origin, does S represent:
> a. the location of the object at time T at the coordinate origin?
> or:
> b. the apparent location of the object as seen from the origin at time 
> T?
> This is especially relevant if spherical coordinates are given - the
> location on the sky where the object IS at time T or where we SEE it at
> time T.
> 
> Just some points to ponder - we need to be explicit about these 
> matters.
> And the example needs some serious work.
> Cheers,
> 
>   - Arnold
> 
> -------------------------------------------------------------------------------------------------------------
> Arnold H. Rots                                          Chandra X-ray
> Science Center
> Smithsonian Astrophysical Observatory                   tel:  +1 617 
> 496
> 7701
> 60 Garden Street, MS 67                                      fax:  +1 
> 617
> 495 7356
> Cambridge, MA 02138
> arots at cfa.harvard.edu
> USA
> http://hea-www.harvard.edu/~arots/
> --------------------------------------------------------------------------------------------------------------
> 
> 
> 
> On Thu, Nov 22, 2018 at 3:51 PM François Bonnarel <
> francois.bonnarel at astro.unistra.fr> wrote:
> 
>> Der Dave, all,*
>> 
>> Before interop Dave asked me to provide how a TimeSeries of Asteroid
>> could look like with the current ts model proposal and Utypes 
>> serialisation.
>> 
>> 
>> 
>> Someone recently described to me a use case that I haven't seen in our
>>  discussions.
>> 
>>  To help me understand how to use the new model, could you send me a
>>  simple example of how a time series of position over time would look 
>> ?
>> 
>>  For a single moving object we would get multiple ra/dec or Point
>>  values plotted against time.
>> 
>>  For a mode complex example, multiple position and magnitude values
>>  plotted against time.
>> 
>> You can find a "dummy example" of this at this URL :
>> http://volute.g-vo.org/svn/trunk/projects/time-domain/time-series/note/DATA/Proposed_Serializations/UTYPES/AsteroidSimple.xml
>> Could be from gaia for an Asteroid. Then Dave gave more details for 
>> the
>> second more complex example
>> 
>> Two use cases from the Gaia meeting.
>> 
>>  Exoplanets, the star will change both brightness and position by tiny
>> amounts linked to the planet's orbit. Very small and slow changes in
>>  both position and brightness, hard to detect above the noise.
>> 
>>  Near earth asteroid will be travelling very fast, and change
>>  brightness in response to distance from the sun, position relative to
>>  the sun, and rotation and shape of the asteroid itself. Very large 
>> and
>>  rapid changes in both position and brightness.
>> 
>>  Both are valid cases for time series of positions and magnitudes.
>> 
>> This is an attempt for a Near Earth Asteroid
>> http://volute.g-vo.org/svn/trunk/projects/time-domain/time-series/note/DATA/Proposed_Serializations/UTYPES/AsteroidFull.xml
>> Data are dummy of course. but with about 1 magnitude amplitude and 
>> 1deg
>> position change in 10 days !!! *Changes for the Exoplanets use case 
>> can
>> be easilly done :* There will be no real "look and feel" change for 
>> the
>> magnitudes. For position, the best is probably to set the mid position 
>> of
>> the star in the refPOsition of COOSYS (see note below) and to have the 
>> lon
>> and lat columns giving the deviation from this  position along the ra 
>> and
>> dec axes (and no more ecliptic longitude and latitude). The unit for 
>> these
>> two columns will probbaly be "mas" instead of "deg".   Cheers François
>> COOSYS note : currently there is no "refPosition" attribute in COOSYS. 
>> We
>> propose to add one , taking the opportunity of the change in VOTable 
>> schema
>> required to introduce TIMESYS. this attribute allows accurate 
>> distinctions
>> of positions computed from BARYCENTER, TOPOCENTER, GEOCENTER, as well 
>> as
>> definitions of standalone "local" spatial frames to code for  very 
>> accurate
>> measurements.
>> 
>>