<div dir="ltr"><div>...  also known as an ephemeris.</div><div><br></div><div>We use a standard FITS file format for orbit and solar system body ephemerides, with 7 columns - time and state vector:</div><div>Time (TT), X, Y, Z, Vx, Vy, Vz</div><div>The state vector is in ITRS, its units m and m/s. All at GEOCENTER.</div><div>The solar system body ephemerides are derived from an ephemeris format that contains:</div><div>Time (TDB), Xs, Ys, Zs, Xe, Ye, Ze</div><div>The position vector for earth (e) and SS object (s) are in ICRS at origin BARYCENTER, their units AU.</div><div><br></div><div>The three points I want to make are:</div><div><br></div><div>1. 3-D Cartesian coordinates are preferable, since you are working in the near field</div><div>ICRS RA and Dec at BARYCENTER, without a solar distance, are useless for conversion to some specific location</div><div><br></div><div>2. State vectors (i.e., adding the spatial time derivatives) are extremely helpful, especially for fast-moving objects</div><div><br></div><div>3. There is one ambiguity that is not addressed here:</div><div>If you provide time T and location S of an object with a common coordinate origin, does S represent:</div><div>a. the location of the object at time T at the coordinate origin?</div><div>or:</div><div>b. the apparent location of the object as seen from the origin at time T?</div><div>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.</div><div><br></div><div>Just some points to ponder - we need to be explicit about these matters.</div><div>And the example needs some serious work.<br></div><div>Cheers,</div><div><br></div><div>  - Arnold<br></div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-------------------------------------------------------------------------------------------------------------<br>Arnold H. Rots                                          Chandra X-ray Science Center<br>Smithsonian Astrophysical Observatory                   tel:  +1 617 496 7701<br>60 Garden Street, MS 67                                      fax:  +1 617 495 7356<br>Cambridge, MA 02138                                         <a href="mailto:arots@cfa.harvard.edu" target="_blank">arots@cfa.harvard.edu</a><br>USA                                                   <a href="http://hea-www.harvard.edu/~arots/" target="_blank">http://hea-www.harvard.edu/~arots/</a><br>--------------------------------------------------------------------------------------------------------------<br><br></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Nov 22, 2018 at 3:51 PM François Bonnarel &lt;<a href="mailto:francois.bonnarel@astro.unistra.fr">francois.bonnarel@astro.unistra.fr</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <pre>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.

 <blockquote type="cite"><pre>Someone recently described to me a use case that I haven&#39;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.</pre>
</blockquote>

You can find a &quot;dummy example&quot; of this at this URL :



<a class="m_-6221293922230461830moz-txt-link-freetext" href="http://volute.g-vo.org/svn/trunk/projects/time-domain/time-series/note/DATA/Proposed_Serializations/UTYPES/AsteroidSimple.xml" target="_blank">http://volute.g-vo.org/svn/trunk/projects/time-domain/time-series/note/DATA/Proposed_Serializations/UTYPES/AsteroidSimple.xml</a>


Could be from gaia for an Asteroid.

Then Dave gave more details for the second more complex example

<blockquote type="cite"><pre>Two use cases from the Gaia meeting.

 Exoplanets, the star will change both brightness and position by tiny 
amounts linked to the planet&#39;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. </pre></blockquote>
This is an attempt for a Near Earth Asteroid
<a class="m_-6221293922230461830moz-txt-link-freetext" href="http://volute.g-vo.org/svn/trunk/projects/time-domain/time-series/note/DATA/Proposed_Serializations/UTYPES/AsteroidFull.xml" target="_blank">http://volute.g-vo.org/svn/trunk/projects/time-domain/time-series/note/DATA/Proposed_Serializations/UTYPES/AsteroidFull.xml</a>

Data are dummy of course. but with about 1 magnitude amplitude and 1deg position change in 10 days !!!

<i><b>Changes for the Exoplanets use case can be easilly done :</b></i>

There will be no real &quot;look and feel&quot; 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 &quot;mas&quot; instead of &quot;deg&quot;. 
 
Cheers

François

COOSYS note : currently there is no &quot;refPosition&quot; 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  &quot;local&quot; spatial frames to code   for
 very accurate  measurements.


</pre>
  </div>

</blockquote></div>