TimeSeries of position (Asteroid)

Sun Nov 25 19:01:23 CET 2018

Dear all,

Since several monthes an IVOA effort started about the question "how to 
represent TimeSeries in the most interoperable" way.

The model project now exists (see presentations at last interop TDIG 
meeting organized by Ada and Dave)

Just have a look to the diagram there:

http://volute.g-vo.org/svn/trunk/projects/time-domain/time-series/note/DATA/Proposed_Serializations/UTYPES/AsteroidSimple.xml 

After the model itself comes the question of VOTABLE annotation 
consistent with this data model.

UTYPES and VODML-mapping proposals exist.

In september Dave went to a Gaia meeting and came out with a question 
about representation of time series of moving positions and varying 
brightness.

This is coming from Gaia, but the motivation was asteroid and exoplanets 
study.

By lack of real data we decided to  create "fake data" just to show the 
annotation. This is actually not that far from the ephemerides provided 
by Rob. Except that we choosed ecliptic J2000.0 coordinates instead of ICRS.

Arnold's proposal is more about representation of a result of an anlysis 
taking into account distance estimation, proper motion and radial 
velocity. I think it could be tackled too beacause the TS data mdel 
relies on STC2 at the low level.

In conclusion I support Dave's idea it should be great to get mode real 
data to represent and annotate. IN the mean time we will strat from 
Rob-provided  ephemeride  and create an IVOA representation of it.

Best regards

François Bonnarel

Le 24/11/2018 à 05:17, Rob Seaman a écrit :
> 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.
>>>>
>>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/voevent/attachments/20181125/e91e43f0/attachment.html>