[nvo-techwg] Time series data

Steve Allen sla at ucolick.org
Mon Jun 11 08:02:37 PDT 2007


On Mon 2007-06-11T09:52:05 -0400, Arnold Rots hath writ:
> It is slightly simpler than the WhereWhen element and it includes
> support for orbital elements.

As of STC 1.30 the orbitType type does not provide support for solar
system orbital elements in the form that they are often expressed, and
it does not at all handle the elements for a parabolic orbit.

It is relatively common with a poorly observed orbit that the semimajor
axis has a huge covariance and that the periapsis distance has a small
one.  This is not to mention the other flavors of expression for the
8 parameters that describe an orbit within the solar system.

I'm attaching what I've been tossing around orbital elements starting
with the VOEvent meeting last week.

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m
-------------- next part --------------
c       The order of the elements in the file is important, and for several
c       of the elements, the SIGN of the element is important.
c       These conventions have been adopted so that the principle form
c       resembles the Astronomical Almanac (Sec. E).  Entering elements with
c       negative signs facilitates inclusion of bodies whose elements are
c       given in IAU Circulars.  The order is given below.
c       '{P|C|A}Name' {a | -q} e i Node {wpi | -w} {M | -L} epoch repoch
c       The quantities are defined as follows.
c                  P(lanet), C(omet), A(steroid)
c            a:    orbital semi-major axis OR mean distance [AU]
c           -q:    perihelion distance [AU]
c            e:    orbital eccentricity
c            i:    inclination of orbit to ecliptic [degrees]
c         Node:    longitude of ascending node on the ecliptic [degrees]
c           wpi:    longitude of perihelion (Ver. Eq.->Node->Perihelion) [degrees]
c           -w:    argument of perihelion (w = wpi - Node) [degrees]
c            M:    mean anomaly at epoch (M = L - wpi) [degrees]
c           -L:    mean longitude at epoch (L = M + wpi) [degrees]
c        epoch:    date at which [L | M] is valid (osculation date) [JD]
c       repoch:    precession epoch for i, Node, {wpi | w} [JD]
c       If q is specified, then the mean longitude/anomaly is ignored and
c       the osculation date (epoch) is presumed to be the perihelion date.
c       Only occassionally will a cometary orbit have an osculation date
c       different than the perihelion date.
c       Upon being read in, all elements are precessed to depoch.

so, taking the cue from what I had working

Constraints in all cases
0 <  a
0 <= q
0 <= e
0 <= i    < 180
0 <= Node < 360
0 <= wpi  < 720
0 <= w    < 360
0 <= M    < 360
0 <= L    < 360

This gives two ways to specify an orbit

For elliptical orbit (specified by "a")
a e i Node (wpi | w) ( M | L) osculationEpoch coordEpoch
8 parameters, two are pairs of alternatives
additional constraint:  e < 1

For orbit with any eccentricity (specified by "q")
q e i Node (wpi | w) perihelionEpoch coordEpoch
7 parameters, one is pair of alternatives

all Epoch in time scale TDB =~ TT (difference irrelevant)

I believe that parameters a q e should have those names
I am open to other names for other params, with likely ones
being something like
Node = Node
w    = argPerihelion                    (used in IAUC,MPEC)
i    = Inclination
wpi  = longPerihelion                   (used in Astronomical Almanac)
M    = meanAnomaly                      (used in IAUC,MPEC)
L    = meanLongitude                    (used in Astronomical Almanac)

The constraints and names here are not appropriate for an ephemeris
for a binary extrasolar object.  I do not know if reports of such
things are common enough that VOEvent would regret being broad enough
to accommodate them.

%%

Okay, just for completeness.

Binary star orbits have these different constraints.

-90 <= i    < 90        only known if there is astrometry and spectroscopy
0   <= Node < 180       measured from N toward E on sky

I don't think wpi (longPerhelion) is ever used for binary stars.
Astrometric binary stars have a in arcsec, not AU.
Spectroscopic binary stars have a in km.
Any binary star also needs P (period), it's not redundant there.
Most binary stars will use epoch of periapsis rather than M or L
So that's

a e i Node w periapsisEpoch coordEpoch P


More information about the voevent mailing list