TimeSeries of position (Asteroid)

[Rob Seaman]

On 11/23/18 7:27 PM, Dave Morris wrote:

> 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?
Not daft.

Objects need to be discovered before they are studied. This is
particularly true for moving objects, for which archival apparitions may
be spread over the whole sky. Astrometric / photometric time series are
at the heart of the discovery process and are traded back-and-forth
nightly between the surveys and professional / amateur follow-up sites.
This is done via the Minor Planet Center's NEO Confirmation Page:

    https://minorplanetcenter.net/iau/NEO/toconfirm_tabular.html

>From the form, select candidate objects to retrieve ephemerides and
observations. These then are passed on to downstream third-party
services such as JPL's Scout:

    https://cneos.jpl.nasa.gov/scout/#/

which calculates impact risk and other quantities. The goal is to
accumulate enough astrometry to confirm an object as a Near Earth
Asteroid (NEA), a comet or other class of objects (e.g., a separate
traffic in astrometry for Trans-Neptunian Objects). Photometry is also
used to constrain orbits and to estimate absolute magnitude, which
correspond roughly to the size of the object depending on the unknown
albedo.

Orbits are estimated via various techniques over lengthening timescales
from minutes to years. Only when objects are eventually assigned an
official IAU number are they eligible for naming (ignoring unique
objects like 'Oumuamua) and this will typically be after recovering the
object over 3-4 solar oppositions (when objects are closest and best
illuminated, often otherwise they are invisible). The great diversity of
asteroid vintages, types, and sizes are accessible from the MPC, but
only after they are assigned a preliminary designation:

    https://minorplanetcenter.net/db_search

There are a variety of use cases to which IVOA would have to add value
for community uptake to take place. For instance, the NEO community is
transitioning to the IAU Astrometric Data Exchange Standard (ADES) which
could be represented by VOEvent, but community momentum ensures this
will not happen.

Rob

--

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