RFC: XML Orbit element type

[dtessman]

I have talked with several people about an XML format for planetary system descriptions. Chris has also shown an interest in using an XML standard for .SCC files within Celestia.

The first fruits of that labor is now published at SpaceGear.Org as a standardized XML Schema Document for Orbit description elements. The new XML Schema element type is EllipticalOrbitType. EllipticalOrbitType will be used as the EllipticalOrbit component of planetary system descriptions.

A description of the XML elements for EllipticalOrbitType is located at http://www.spacegear.org/schemas/. This description page includes a link to the actual XML Schema Document.

If this interests you, please take a look at it and post your comments here or at SpaceGear.Org. We still have a long way to go and are looking for your feedback.

Thanks,

[chris]

Looks pretty good to me . . . I have a couple suggestions, though. It should be possible to specify the epoch as a Julian date. The epoch element should have an attribute that specifies whether the text gives a Julian Date or UTC. The name of the tag should be changed to EllipticalOrbit or KeplerianOrbit, to distinguish it from other orbital models. Celestia uses two types of orbits now--elliptical (actually parabolic and hyperbolic as well) and 'custom' orbits coded in C++.

--Chris

[dtessman]

It should be possible to specify the epoch as a Julian date. The epoch element should have an attribute that specifies whether the text gives a Julian Date or UTC.

Following Herschel's lead astronomers adopted this system and took noon GMT -4712-01-01 J (January 1st, 4713 B.C.) as their zero point. (Note that 4713 B.C. is the year -4712 according to the astronomical year numbering.) For astronomers a Julian day begins at noon and runs until the next noon (so that the nighttime falls conveniently within one "day", unless they are making their observations in a place such as Australia). Thus they defined the Julian day number of a day as the number of days (or part of a day) elapsed since noon GMT (or more exactly, UT) on January 1st, 4713 B.C., in the Proleptic Julian Calendar.

Thus the Julian day number of noon GMT on -4712-01-01 (Julian), or more casually, the Julian day number of -4712-01-01 itself, is 0. The Julian day number of 1996-03-31 is 2,450,174 — meaning that on 1996-03-31 2,450,174 days had elapsed since -4712-01-01 (or more exactly, that at noon on 1996-03-31 2,450,174 days had elapsed since noon on -4712-01-01).

A decimal component may be used, so that JD 0.5 is the midnight point separating -4712-01-01 J and -4712-01-02 J, JD 1.25 is 6 p.m. on -4712-01-02 J, and so on.

So it is a simple unformatted float. Correct?
Such as 2452028.18381755.
What do you suggest as the unit value? How about "jd"?
So the tag would be <Epoch unit="jd">2452028.18381755</Epoch>?

The name of the tag should be changed to EllipticalOrbit or KeplerianOrbit, to distinguish it from other orbital models.

Agreed.
I went ahead and made the changes.
http://www.spacegear.org/schemas/
Please check it out and let me know, if we have arrived.

Thanks,

[HankR]

I believe that for objects in solar orbit, osculating elements are commonly given with respect to the earth's orbital plane (ecliptic) and equatorial plane. These reference planes are often specified at a standard epoch which is different from the epoch of the elements. (See http://ssd.jpl.nasa.gov/sb_elem.html for details). Mean elements for satellites are also sometimes referenced to the ecliptic, rather than the equator of the primary. Other reference planes (Laplacian) are also sometimes used. (See http://ssd.jpl.nasa.gov/sat_elem.html for examples). It might be useful if the XML format could accomodate the forms in which real orbital elements are typically available.

- Hank

[dtessman]

I believe that for objects in solar orbit, osculating elements are commonly given with respect to the earth's orbital plane (ecliptic) and equatorial plane. These reference planes are often specified at a standard epoch which is different from the epoch of the elements. (See http://ssd.jpl.nasa.gov/sb_elem.html for details). Mean elements for satellites are also sometimes referenced to the ecliptic, rather than the equator of the primary. Other reference planes (Laplacian) are also sometimes used. (See http://ssd.jpl.nasa.gov/sat_elem.html for examples). It might be useful if the XML format could accomodate the forms in which real orbital elements are typically available.

The Sol system celestial sphere is based on the equator of earth. This means that the orbits of all the planets are inclined to create the ecliptic. If the Sol system used the ecliptic as its celestial equator, then the orbits would be less inclined (no pun intended ). However most of the known planetary data for Sol are based on a celestia equator that matches Earth. BUT! some objects are based on the ecliptic rather that the celestial equator. So to add those objects, one needs to get out the calculator to fiddle with the inclination of each object's orbit... yuck.

The schema handles reference systems based on the parent's inclination. The parent for Phobos would be Mars. However this still does not handle perturbed orbits. Any thoughts on how to handle orbital precession ?

The Ecliptic as a parent reference system is also missing.

[dtessman]

One could create an ecliptic coordinate reference and just use that as the parent. This being something that can be a parent, but is not a real object. I know it seems wierd to assign obliquity to barycenter, but we will need a barycenter object anyway to have a couple objects orbiting each other at some location other than the star system origin. Having that include a reference system seems to makes sense.

This is the equivalent of the star system origin (0,0):
<Barycenter/>

This defines the ecliptic:
<Barycenter id="ecliptic">
<Obliquity>23.4</Obliquity>
</Barycenter>

This orbit of some object is referenced to the ecliptic:
<EllipticalOrbit>
<Parent>ecliptic</Parent>
....
</EllipticalOrbit>

Yet another way to look at it in the Sol system, is to make the celestial sphere be the star system reference coordinates and use the Sun itself as the reference for the ecliptic.

<Star id="sol>
<Obliquity>23.4</Obliquity>
...
</Star>

Orbit of some object referenced by the ecliptic:
<EllipticalOrbit>
<Parent>sol</Parent>
...
</EllipticalOrbit>

Orbit of some object referenced by the celestia sphere and origin (0,0):
<EllipticalOrbit>
...
</EllipticalOrbit>

I think both are certainly possible and probably needed under various circumstances.

[HankR]

I'm no expert in this by any means. The following comments are based only on my limited understanding.

Orbital motion is very complex. Elliptical (Keplerian) orbits are a gross simplification which treat the object and its primary as isolated point masses. This is a reasonable approximation for major planets, but much less so for natural satellites and especially low-orbiting spacecraft. Even for major planets, Keplerian orbits are reasonable approximations only over limited time intervals.

So-called "osculating" elements describe the instantaneous motion of an object as if it were in a Keplerian orbit with respect to its primary at a specific point in time. This point in time is called the epoch of the elements. The position and velocity of the object at the moment of the epoch can be derived from the elements, and vice versa. Positions of the object at times other than the epoch can be calculated from the elements, based on the assumption that the object moves in a Keplerian orbit, but the result will be increasingly inaccurate as the time difference from the epoch increases (because the true motion is not Keplerian). New elements are required for adequate accuracy at times beyond a limited interval around the epoch.

Elements of this type are commonly used for minor planets (asteroids) and comets, and are available from various on-line sources. As indicated above, they are only accurate near the appropriate epoch. For longer intervals, multiple element sets could be used with interpolation between epochs.

For a given set of elements, there is an additional issue concerning the reference system used to define the elements. The inclination and the longtitude of the ascending node (both angles) are specified with respect to a reference plane and direction. For solar orbits, the reference plane is usually the ecliptic, which is the plane of the earth's orbit, and the reference direction is the line of intersection between the ecliptic plane and the earth's equatorial plane. Because of the complexity of the earth's motion, both of these planes change their orientation over time, so the elements are specified with respect to the orientation of these planes at a specific time, also called an epoch. This is not necessarly (nor usually) the same time as the epoch of the elements themselves. Usually certain standard reference systems are used, based on specific epochs such as 1/1/2000 etc.

- Hank

[dtessman]

Does it make sense to remove Epoch and Parent from EllipticalOrbit and place it within the enclosing element?

Why?
Parent makes more sense within the orbiting body representation. Luna is a child of Earth.
Epoch is used by the orbiting body, for such things as rotation offset, which is not part of orbit.

So it would look something like this:

Code: Select all

<Moon id="luna">
    <Parent>earth</Parent>
    <Epoch unit="jd">2452028.18381755</Epoch>
    ...
    <RotationPeriod>28.35</RotationPeriod>
    <RotationOffset>43</RotationOffset>
    ...
    <EllipticalOrbit>
        <Period unit="day">28.35</Period>
    ...
    </EllipticalOrbit>
</Moon>

Comments?

[chris]

Does it make sense to remove Epoch and Parent from EllipticalOrbit and place it within the enclosing element?

Why?
Parent makes more sense within the orbiting body representation. Luna is a child of Earth.
Epoch is used by the orbiting body, for such things as rotation offset, which is not part of orbit.

I think that parent should not be part of EllipticalOrbit, but Epoch should be left there . . . RotationElements should have it's own Epoch, as it's quite possible that you'd have a separate epochs for the orbit and the rotation elements. I'm not sure if EllipticalOrbit is the right name, since it would be useful to allow eccentricities >= 1 for parabolic and hyperbolic orbits. Introducing separate ParabolicOrbit and HyperbolicOrbit elements to accommodate is senseless . . . How about KeplerianOrbit?

Also, as HankR pointed out, there are two different uses of epoch. One is the epoch of the orbital parameters, and the other is the epoch of the reference coordinate system. Figuring out a method to specify a reference coordinate system that's flexible enough to handle planets, moons, asteroids, etc. in any solar system is going to be a hairy problem, and I'm content to ignore it for the moment

--Chris

[dtessman]

I think that parent should not be part of EllipticalOrbit, but Epoch should be left there . . . RotationElements should have it's own Epoch, as it's quite possible that you'd have a separate epochs for the orbit and the rotation elements.

Good points. I will make the modifications when I put together and publish the enclosing elements.

I'm not sure if EllipticalOrbit is the right name, since it would be useful to allow eccentricities >= 1 for parabolic and hyperbolic orbits. Introducing separate ParabolicOrbit and HyperbolicOrbit elements to accommodate is senseless . . . How about KeplerianOrbit?

EllipticalOrbit was bothering me too. I don't have a problem with using KeplerianOrbit.
Other than custom orbit (which is really a code thing and not a data thing). Aren't all orbits elliptical? ParabolicOrbit is actually a trajectory isn't it?

Also, as HankR pointed out, there are two different uses of epoch. One is the epoch of the orbital parameters, and the other is the epoch of the reference coordinate system. Figuring out a method to specify a reference coordinate system that's flexible enough to handle planets, moons, asteroids, etc. in any solar system is going to be a hairy problem, and I'm content to ignore it for the moment :)

Ignorance is bliss. I don't want to touch that one yet either.

[MKruer]

Although not official yet, Tags should have two ways to be formatted.

<data unit="num">#####</data>
or
<data unit="num" value="#####"/>

Data is the Tag Name
Units, RGB, Speed, etc... Are the attributes for the tag
Value attribute will always be the information. (Note if you do not have a value option, the value become what’s between the opening and closing tag for that item.)

This is the structure(s) of all the Tags. It will allow for nesting and the ability to write the tag the XML shorthand.

Each tag has its own set of attributes and defaults (TBA)

What I need help in is finding out all top level objects, and all sublevels for those objects.

I believe I have identified All Top Level Object Types

Node (Point of Reference for center of mass in multiple star systems)
Star (Back Holes, Pulsars, etc...)
Planet (Rocky, Gas Giants, etc...)
Planetoid (Specific Object)
PlanetoidBelt (Planetoid Belt/Ring)
PlanetoidField (Planetoid Field)
Comet

I have created an excel spread sheet to help build a matrix of all objects tags and attributes.

http://www.linkline.com/personal/mkruer ... 0Sheet.xls

If you have any sugestions please reply here.

-Matt-

[dtessman]

Chris,

I was kinda serious about the trajectory comment. Are there really any other types of orbits other than Elliptical Keplerian Orbits?

Custom orbits I don't count because they are implemented in code. Why not just call the element Orbit? (Custom orbit information could be called CustomOrbit) I really don't have a problem calling it KeplerianOrbit. But is it really necessary?

Thanks,

[dtessman]

I am thinking of making Period optional. If it does not exist, then it is calculated from the semi-major axis and mass of the parent.
Your thoughts?

[selden]

I can think of a couple of reasons why including the period might be appropriate.

The period is determined by the mass of the primary (well actually the sum of the primary's and orbiting body's masses). E.g. a planet orbiting a star more massive than the Sun would have a shorter period than a planet orbiting the sun when in an orbit with the same SemiMajorAxis value.

Also, it sometimes may be convenient to compensate for long term gravitational effects (as for Trojan asteroids near Lagrange points) by using slightly non-physical periods.

[MKruer]

dtessman writes

mkruer writes

Although not official yet, Tags should have two ways to be formatted.

<data unit=\"num\">#####</data>
or
<data unit=\"num\" value=\"#####\"/>

Data is the Tag Name
Units, RGB, Speed, etc... Are the attributes for the tag
Value attribute will always be the information. (Note if you do not have a value option, the value become what’s between the opening and closing tag for that item.)

Matt,
I see more disadvantages than advantages to allowing this in data oriented tags (such as Period).

Advantages:
Usually will be shorter to write (if tag name exceeds 6 characters in length).

Disadvantages:
Doubles the size of the XML Schema for the element.
Requires parser programmers to check for attribute and element contents.
Could cause confusion as to when it is allowed and when it is not.

Do you have any references where this is discussed. I have seen it used before and have some examples of how to code it in my XML Schema text. But I need some convincing.

Disadvantages:
1. Doubles the size of the XML Schema for the element.
Not really. More like add an additional note.
2. Requires parser programmers to check for attribute and element contents.
Believe it or not it’s easier to parser then having to keep track of all the open and close tags. Don’t believe me try programming. And besides you would have to do it any way unless you are throwing out the attributes all together. If you do then you have just taken away ALL of flexibility of XML
3. Could cause confusion as to when it is allowed and when it is not.
This is the only one that you may have correct for the simple reason of nesting. Other then that nope.