Class FramesFactory

FramesFactory Presentation

Several predefined reference frames are implemented in OREKIT.
They are linked together in a tree with the Geocentric
Celestial Reference Frame (GCRF) as the root of the tree.
This factory is designed to:

build the frames tree consistently,

avoid rebuilding some frames that may be costly to recreate all the time,

set up interpolation/caching features for some frames that may induce costly computation

International Terrestrial Reference Frame

This frame is the current (as of 2013) reference realization of
the International Terrestrial Reference System produced by IERS.
It is described in
IERS conventions (2010). It replaces the Earth Centered Earth Fixed
frame which is the reference frame for GPS satellites.

This frame is used to define position on solid Earth. It rotates with
the Earth and includes the pole motion with respect to Earth crust as
provided by IERS data.
Its pole axis is the IERS Reference Pole (IRP).

ITRF can be built using the new non-rotating origin paradigm
mandated by IAU 2000 resolution B1.8 and any supported IERS conventions (even IERS 1996 can be used with non-rotating origin paradigm,
despite the resolution was not yet adopted at conventions publication time.

ITRF can also be built using the classical equinox paradigm used prior to IAU 2000
resolution B1.8 and any supported IERS conventions (even
IERS 2003 and 2010 can be used with equinox paradigm, despite the resolution is
in effect now). The choice of paradigm (non-rotating origin or equinox) and the
choice of IERS conventions (i.e. the choice of precession/nutation models) can
be made independently by user, Orekit provides all alternatives.

Intermediate frames

Orekit also provides all the intermediate frames that are needed to transform
between GCRF and ITRF, along the two paths: ITRF/TIRF/CIRF/GCRF for the
non-rotating origin paradigm and ITRF/GTOD/TOD/MOD/EME2000/GCRF for the equinox
paradigm.

Earth Orientation Parameters

This factory also handles loading of Earth Orientation Parameters (EOP) needed
for accurate transformations between inertial and Earth fixed frames, using
DataProvidersManager features. EOP are IERS conventions
dependent, because they correspond to correction to the precession/nutation
models. When EOP should be applied, but EOP data are not available, then a null
(0.0) correction is used. This can occur when no EOP data is loaded, or when the
requested date is beyond the time span of the loaded EOP data. Using a null
correction can result in coarse accuracy. To check the time span covered by EOP data use
getEOPHistory(IERSConventions, boolean), EOPHistory.getStartDate(),
and EOPHistory.getEndDate().

setEOPContinuityThreshold

The default threshold (used if this method is never called)
is 5 Julian days. If after loading EOP entries some holes
between entries exceed this threshold, an exception will
be triggered.

One case when calling this method is really useful is for
applications that use a single Bulletin A, as these bulletins
have a roughly one month wide hole for the first bulletin of
each month, which contains older final data in addition to the
rapid data and the predicted data.

getEcliptic

Get the ecliptic frame.
The IAU defines the ecliptic as "the plane perpendicular to the mean heliocentric
orbital angular momentum vector of the Earth-Moon barycentre in the BCRS (IAU 2006
Resolution B1)." The +z axis is aligned with the angular momentum vector, and the +x
axis is aligned with +x axis of MOD.

This implementation agrees with the JPL 406 ephemerides to within 0.5 arc seconds.

getGTOD

The applyEOPCorr parameter is available mainly for testing purposes or for
consistency with legacy software that don't handle EOP correction parameters.
Beware that setting this parameter to false leads to crude accuracy
(order of magnitudes for errors might be above 250m in LEO and 1400m in GEO).
For this reason, setting this parameter to false is restricted to IERS 1996 conventions, and hence the IERS conventions cannot be freely chosen here.

getTOD

The applyEOPCorr parameter is available mainly for testing purposes or for
consistency with legacy software that don't handle EOP correction parameters.
Beware that setting this parameter to false leads to crude accuracy
(order of magnitudes for errors might be above 1m in LEO and 10m in GEO).
For this reason, setting this parameter to false is restricted to IERS 1996 conventions, and hence the IERS conventions cannot be freely chosen here.

getMOD

The applyEOPCorr parameter is available mainly for testing purposes or for
consistency with legacy software that don't handle EOP correction parameters.
Beware that setting this parameter to false leads to crude accuracy
(order of magnitudes for errors might be above 1m in LEO and 10m in GEO).
For this reason, setting this parameter to false is restricted to IERS 1996 conventions, and hence the IERS conventions cannot be freely chosen here.

getTEME

The TEME frame is used for the SGP4 model in TLE propagation. This frame has no
official definition and there are some ambiguities about whether it should be used
as "of date" or "of epoch". This frame should therefore be used only for
TLE propagation and not for anything else, as recommended by the CCSDS Orbit Data Message
blue book.

getNonInterpolatingTransform

This method is similar to Frame.getTransformTo(Frame, AbsoluteDate)
except it removes the performance enhancing interpolation features that are
added by the factory to some frames, in order to focus
on accuracy. The interpolation features are intended to save processing time
by avoiding doing some lengthy computation like nutation evaluation at each
time step and caching some results. This method can be used to avoid this,
when very high accuracy is desired, or for testing purposes. It should be
used with care, as doing the full computation is really costly for
some frames.