See: Description
Interface | Description |
---|---|
BodyShape |
Interface representing the rigid surface shape of a natural body.
|
CelestialBody |
Interface for celestial bodies like Sun, Moon or solar system planets.
|
CelestialBodyLoader |
Interface for loading celestial bodies.
|
IAUPole |
Interface for IAU pole and prime meridian orientations.
|
JPLEphemeridesLoader.RawPVProvider |
Interface for raw position-velocity retrieval.
|
Class | Description |
---|---|
CelestialBodyFactory |
Factory class for bodies of the solar system.
|
Ellipse |
Model of a 2D ellipse in 3D space.
|
Ellipsoid |
Modeling of a general three-axes ellipsoid.
|
FieldGeodeticPoint<T extends org.hipparchus.RealFieldElement<T>> |
Point location relative to a 2D body surface, using
RealFieldElement . |
GeodeticPoint |
Point location relative to a 2D body surface.
|
JPLEphemeridesLoader |
Loader for JPL ephemerides binary files (DE 4xx) and similar formats (INPOP 06/08/10).
|
OneAxisEllipsoid |
Modeling of a one-axis ellipsoid.
|
Enum | Description |
---|---|
JPLEphemeridesLoader.EphemerisType |
List of supported ephemerides types.
|
The position of celestial bodies is represented by the CelestialBody
interface. This interface provides the methods
needed to either consider the body as an external one for its gravity or lighting
influence on spacecraft (typically in perturbing force computation) or as an internal
one with its own frame.
The CelestialBodyFactory
class is a factory providing several
predefined instances implementing the CelestialBody
interface for the main solar system bodies. The Sun, the Moon, the eight planets and
the Pluto dwarf planet are the supported bodies. In addition to these real bodies,
two points are supported for convenience as if they were real bodies: the solar system
barycenter and the Earth-Moon barycenter. The CelestialBodyFactory
factory relies on the JPL DE 405, 406 or similar binary ephemerides files to compute all
positions and velocities. Note that the binary files are used, not the ASCII ones,
regardless of the processor endianness.
As an example, computing the position of the Sun and the Moon in the EME2000 frame, this done as follows:
CelestialBody sun = CelestialBodyFactory.getSun(); CelestialBody moon = CelestialBodyFactory.getMoon(); Vector3D sunInEME2000 = sun.getPVCoordinates(date, Frame.getEME2000()).getPosition(); Vector3D moonInEME2000 = moon.getPVCoordinates(date, Frame.getEME2000()).getPosition();
Since the supported bodies implement the CelestialBody
interface, they all provide their own body-centered inertial frame, hence adding a few
more frames to the ones provided by the org.orekit.frames
package. Since the
frames tree is rooted at an Earth-centered frame, the solar system bodies frames tree
does not seems in canonical shape. This of course is only a side effect of the
arbitrary choice of GCRF as the root frame and has no effect at all on computations.
The shape of celestial bodies is represented by the BodyShape
interface.
Only one implementation is provided by OREKIT for now: the OneAxisEllipsoid
class which represents the natural flattened shape
of big space rotating bodies like planets or the Sun.
For asteroids, it is expected that users provide their own shape models, for example
based on triangulation. They should implement the BodyShape
interface in order to be used by Orekit.
When using OneAxisEllipsoid
body representation, points are
generally described in associated body frame, by so-called geodetic coordinates
(longitude, latitude, altitude). The GeodeticPoint
class allows
handling of such coordinates. It is a simple container that does not provide processing
methods.
Copyright © 2002-2017 CS Systèmes d'information. All rights reserved.