<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Dear all,</p>
<p>Since several monthes an IVOA effort started about the question
"how to represent TimeSeries in the most interoperable" way.</p>
<p>The model project now exists (see presentations at last interop
TDIG meeting organized by Ada and Dave)</p>
<p>Just have a look to the diagram there:<br>
</p>
<p><a class="moz-txt-link-freetext"
href="http://volute.g-vo.org/svn/trunk/projects/time-domain/time-series/note/DATA/Proposed_Serializations/UTYPES/AsteroidSimple.xml">http://volute.g-vo.org/svn/trunk/projects/time-domain/time-series/note/DATA/Proposed_Serializations/UTYPES/AsteroidSimple.xml</a>
<br>
</p>
<p>After the model itself comes the question of VOTABLE annotation
consistent with this data model.</p>
UTYPES and VODML-mapping proposals exist.<br>
<p>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.<br>
</p>
<p>This is coming from Gaia, but the motivation was asteroid and
exoplanets study.<br>
</p>
<p>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.</p>
<p>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.</p>
<p><br>
</p>
<p>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. <br>
</p>
<p>Best regards</p>
<p>François Bonnarel<br>
</p>
<p><br>
</p>
<br>
<div class="moz-cite-prefix">Le 24/11/2018 à 05:17, Rob Seaman a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:4ac56ce8-caba-0612-3a6f-a46eef84bf0d@lpl.arizona.edu">
<pre wrap="">On 11/23/18 7:27 PM, Dave Morris wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">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:
<a class="moz-txt-link-freetext" href="https://minorplanetcenter.net/iau/NEO/toconfirm_tabular.html">https://minorplanetcenter.net/iau/NEO/toconfirm_tabular.html</a>
>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:
<a class="moz-txt-link-freetext" href="https://cneos.jpl.nasa.gov/scout/#/">https://cneos.jpl.nasa.gov/scout/#/</a>
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:
<a class="moz-txt-link-freetext" href="https://minorplanetcenter.net/db_search">https://minorplanetcenter.net/db_search</a>
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
--
</pre>
<blockquote type="cite">
<pre wrap="">On 2018-11-23 20:53, Arnold Rots wrote:
</pre>
<blockquote type="cite">
<pre wrap="">... 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
<a class="moz-txt-link-abbreviated" href="mailto:arots@cfa.harvard.edu">arots@cfa.harvard.edu</a>
USA
<a class="moz-txt-link-freetext" href="http://hea-www.harvard.edu/%7Earots/">http://hea-www.harvard.edu/~arots/</a>
--------------------------------------------------------------------------------------------------------------
On Thu, Nov 22, 2018 at 3:51 PM François Bonnarel <
<a class="moz-txt-link-abbreviated" href="mailto:francois.bonnarel@astro.unistra.fr">francois.bonnarel@astro.unistra.fr</a>> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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 :
<a class="moz-txt-link-freetext" href="http://volute.g-vo.org/svn/trunk/projects/time-domain/time-series/note/DATA/Proposed_Serializations/UTYPES/AsteroidSimple.xml">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
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
<a class="moz-txt-link-freetext" href="http://volute.g-vo.org/svn/trunk/projects/time-domain/time-series/note/DATA/Proposed_Serializations/UTYPES/AsteroidFull.xml">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 !!! *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.
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<br>
</body>
</html>