Skip to content
Snippets Groups Projects
Commit cea82b17 authored by Luc Maisonobe's avatar Luc Maisonobe
Browse files

Various fixes on the generated site.

parent b5a4abbe
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
pom.xml
+ 30
− 2
View file @ cea82b17
......@@ -83,11 +83,39 @@
</licenses>
<scm>
<connection>scm:git:http://www.orekit.org/git/rugged</connection>
<developerConnection>scm:git:ssh://git@www.orekit.org/rugged.git</developerConnection>
<connection>scm:git:https://www.orekit.org/git/rugged-main.git</connection>
<developerConnection>scm:git:ssh://git@www.orekit.org/rugged-main.git</developerConnection>
<url>https://www.orekit.org/forge/projects/rugged/repository</url>
</scm>
<issueManagement>
<system>Redmine</system>
<url>https://www.orekit.org/forge/projects/rugged/issues</url>
</issueManagement>
<mailingLists>
<mailingList>
<name>Shared Orekit/Rugged announces mailing list</name>
<subscribe>https://www.orekit.org/wws/subscribe/orekit-announces</subscribe>
<unsubscribe>https://www.orekit.org/wws/signoff/orekit-announces</unsubscribe>
<archive>https://www.orekit.org/wws/arc/orekit-announces</archive>
</mailingList>
<mailingList>
<name>Rugged users mailing list</name>
<subscribe>https://www.orekit.org/wws/subscribe/rugged-users</subscribe>
<unsubscribe>https://www.orekit.org/wws/signoff/rugged-users</unsubscribe>
<post>rugged-users@orekit.org</post>
<archive>https://www.orekit.org/wws/arc/rugged-users</archive>
</mailingList>
<mailingList>
<name>Rugged developers mailing list</name>
<subscribe>https://www.orekit.org/wws/subscribe/rugged-developers</subscribe>
<unsubscribe>https://www.orekit.org/wws/signoff/rugged-developers</unsubscribe>
<post>rugged-developers@orekit.org</post>
<archive>https://www.orekit.org/wws/arc/rugged-developers</archive>
</mailingList>
</mailingLists>
<modules>
<module>core</module>
<module>aster</module>
......
src/site/markdown/configuration.md
+ 1
− 1
View file @ cea82b17
......@@ -28,7 +28,7 @@ first time, you will add the following code snippet:
File home = new File(System.getProperty("user.home"));
File orekitData = new File(home, "orekit-data");
DataProvidersManager.addProvider(new DirectoryCrawler(orekitData));
DataProvidersManager.getInstance().addProvider(new DirectoryCrawler(orekitData));
This is sufficient to start working.
......
src/site/markdown/contact.md
+ 4
− 3
View file @ cea82b17
......@@ -18,13 +18,14 @@ Contacts
Mailing lists
-------------
Most discussions should occur on the public mailing lists.
Most discussions should occur on the public mailing lists. As Rugged
heavily depends on Orekit, they share the same low traffic announces list.
| topic | post address | subscribe URL | archive URL |
|---------------|------------------------------|--------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------|
| announces | orekit-announces@orekit.org | [https://www.orekit.org/wws/subscribe/orekit-announces](https://www.orekit.org/wws/subscribe/orekit-announces) | [https://www.orekit.org/wws/arc/orekit-announces](https://www.orekit.org/wws/arc/orekit-announces) |
| users | orekit-users@orekit.org | [https://www.orekit.org/wws/subscribe/orekit-users](https://www.orekit.org/wws/subscribe/orekit-users) | [https://www.orekit.org/wws/arc/orekit-users](https://www.orekit.org/wws/arc/orekit-users) |
| developers | orekit-developers@orekit.org | [https://www.orekit.org/wws/subscribe/orekit-developers](https://www.orekit.org/wws/subscribe/orekit-developers) | [https://www.orekit.org/wws/arc/orekit-developers](https://www.orekit.org/wws/arc/orekit-developers) |
| users | rugged-users@orekit.org | [https://www.orekit.org/wws/subscribe/rugged-users](https://www.orekit.org/wws/subscribe/rugged-users) | [https://www.orekit.org/wws/arc/rugged-users](https://www.orekit.org/wws/arc/rugged-users) |
| developers | rugged-developers@orekit.org | [https://www.orekit.org/wws/subscribe/rugged-developers](https://www.orekit.org/wws/subscribe/rugged-developers) | [https://www.orekit.org/wws/arc/rugged-developers](https://www.orekit.org/wws/arc/rugged-developers) |
Please register to these mailing lists before attempting to post!
......
src/site/markdown/design/overview.md
+ 18
− 18
View file @ cea82b17
......@@ -53,21 +53,21 @@ Functional Breakdown
The following table sorts out the various topics between the various layers.
:--------------------------------:|:-----------------------:|:---------------------------------------------------------------------------------------------------|
Topic | Layer | Comment
Sensor to ground mapping | Rugged | Direct localization is the base feature provided
Ground to sensor mapping | Rugged | Inverse localization is another base feature provided
Individual pixels | Rugged |The API supports any number of pixels, defined by their individual line of sight provided by caller
Optical path | Interface |The folded optical path inside the spacecraft is taken into account by computing an overall transform combining all inside reflections, so each pixel position and line of sight can be computed later on by a single translation and rotation with respect to spacecraft center of mass
Line time-stamping | Interface/Rugged |The caller must provide a simple time-stamping model (typically linear) that will be applied
Orbit and attitude interpolation | Orekit |Both simple interpolation from timestamped position samples and full orbit propagation are available, thanks to Orekit streamlined propagator architecture
CCSDS Orbit/Attitude file parsing | Orekit |This is supported as long as standard CCSDS Orbit Data Message (CCSDS 502.0-B-2) and CCSDS Attitude Data Messages (CCSDS 504.0-B-1) are used
Custom Orbit/Attitude file parsing| Interface |Custom files can be loaded by mission specific readers, and the list or orbit/attitude states can be provided to Orekit which is able to handle interpolation from these sample data
Frames transforms | Orekit |Full support to all classical reference inertial and Earth frames is already provided by Orekit (including the legacy EME2000, MOD, TOD, but also the more modern GCRF, ICRF, TIRF or exotic frames like TEME or Veis1950, as well as several versions of ITRF)
IERS data correction | Orekit |All frame transforms support the full set of IERS Earth Orientation Parameters corrections, including of course the large DUT1 time correction, but also the smaller corrections to older IAU-76/80 or newer IAU-2000/2006 precession nutation models as well as the polar wander. The frames level accuracy is at sub-millimeter level
Grid-post elevation model | Rugged |Only raster elevation models are supported
Triangulated Irregular Network elevation model | Not supported |If vector elevation models are needed, they must be converted to raster form in order to be used
Geoid computation | Not in version 1 |The first version only supports Digital Elevation Models computed with respect to a reference ellipsoid. If needed, this feature could be added after version 1, either at Rugged or Orekit level, using Orekit gravity fields
Time-dependent deformations | Interface/Rugged |The caller must supply a simple line-of-sight model (typically polynomial) that will be applied
Calibration |Image processing or interface|The calibration phase remains at the mission-specific caller level (pixels geometry, clock synchronization …), the caller is required to provide the already calibrated line of sights
DEM file parsing | Interface |The elevation models are dedicated to the mission and there are several formats (DTED, GeoTIFF, raw data …).Rugged only deals with raw elevation on small latitude/longitude cells
| Topic | Layer | Comment
|----------------------------------|-------------------------|-----------------------------------------------------------------------------
| Sensor to ground mapping | Rugged | Direct localization is the base feature provided
| Ground to sensor mapping | Rugged | Inverse localization is another base feature provided
| Individual pixels | Rugged |The API supports any number of pixels, defined by their individual line of sight provided by caller
| Optical path | Interface |The folded optical path inside the spacecraft is taken into account by computing an overall transform combining all inside reflections, so each pixel position and line of sight can be computed later on by a single translation and rotation with respect to spacecraft center of mass
| Line time-stamping | Interface/Rugged |The caller must provide a simple time-stamping model (typically linear) that will be applied
|Orbit and attitude interpolation | Orekit |Both simple interpolation from timestamped position samples and full orbit propagation are available, thanks to Orekit streamlined propagator architecture
|CCSDS Orbit/Attitude file parsing | Orekit |This is supported as long as standard CCSDS Orbit Data Message (CCSDS 502.0-B-2) and CCSDS Attitude Data Messages (CCSDS 504.0-B-1) are used
|Custom Orbit/Attitude file parsing| Interface |Custom files can be loaded by mission specific readers, and the list or orbit/attitude states can be provided to Orekit which is able to handle interpolation from these sample data
| Frames transforms | Orekit |Full support to all classical reference inertial and Earth frames is already provided by Orekit (including the legacy EME2000, MOD, TOD, but also the more modern GCRF, ICRF, TIRF or exotic frames like TEME or Veis1950, as well as several versions of ITRF)
| IERS data correction | Orekit |All frame transforms support the full set of IERS Earth Orientation Parameters corrections, including of course the large DUT1 time correction, but also the smaller corrections to older IAU-76/80 or newer IAU-2000/2006 precession nutation models as well as the polar wander. The frames level accuracy is at sub-millimeter level
| Grid-post elevation model | Rugged |Only raster elevation models are supported
|Triangulated Irregular Network elevation model | Not supported |If vector elevation models are needed, they must be converted to raster form in order to be used
| Geoid computation | Not in version 1 |The first version only supports Digital Elevation Models computed with respect to a reference ellipsoid. If needed, this feature could be added after version 1, either at Rugged or Orekit level, using Orekit gravity fields
| Time-dependent deformations | Interface/Rugged |The caller must supply a simple line-of-sight model (typically polynomial) that will be applied
| Calibration |Image processing or interface|The calibration phase remains at the mission-specific caller level (pixels geometry, clock synchronization …), the caller is required to provide the already calibrated line of sights
| DEM file parsing | Interface |The elevation models are dedicated to the mission and there are several formats (DTED, GeoTIFF, raw data …).Rugged only deals with raw elevation on small latitude/longitude cells
src/site/markdown/design/technical-choices.md
+ 49
− 36
View file @ cea82b17
......@@ -18,48 +18,61 @@ Earth frames
As Rugged is built on top of Orekit and Apache Commons Math, all the flight dynamics and
mathematical computation are delegated to these two libraries and the full accuracy available
is used. This implies for example that when computing frames conversions between the inertial
frame and the Earth frame, the complete set of IERS1 Earth Orientation Parameters (EOP)
frame and the Earth frame, the complete set of IERS Earth Orientation Parameters (EOP)
corrections is applied if the IERS files are available. This may lead to results slightly
different from the one produced by some other geometry correction libraries that are limited
to the older equinox-based paradigm (Mean Of Date and True Of Date), apply only DUT1 and pole
wander corrections and ignore the other Earth Orientation Parameters corrections. The expected
difference with such libraries is due to the missing corrections (δΔε and δΔψ for equinox-based
paradigm) to the IAU-1980 precession (Lieske) and nutation (Wahr) models used in the legacy MOD
and TOD frames. The error is plotted below, showing the coordinates of three points along the three
canonical X, Y and Z axes, roughly at Earth radius. The plot shows a clear regular signal with
several harmonics, which correspond to the nutation components that were not in this older model.
This error was small in the 80's but is much higher now (as of 2014, it is of the order of magnitude
of 3 meters). The error is steadily increasing.
paradigm) to the IAU-1980 precession (Lieske) and nutation (Wahr) models used in the legacy
MOD and TOD frames.
The following figure is a plot of this error, showing the coordinates of three Earth points
along the three canonical X, Y and Z axes, roughly at Earth radius. The plot shows a clear
regular signal with several harmonics, which correspond to the nutation components that were
not in this older model. This error was small in the 80's but is much higher now (as of 2014,
it is of the order of magnitude of 3 meters). The error is steadily increasing.
![precession/nutation error](../images/ignoring-EOP-1996.png)
As Rugged delegates computation to Orekit, the full set of corrections (DUT1, pole wander, lod, δΔε/δΔψ
or δx/δy) are automatically loaded and applied. The final accuracy obtained when all EOP are considered
is at sub-millimeter level in position, and the expected difference with libraries ignoring δΔε and δΔψ
is at a few meters level, Rugged being the more accurate one.
Note that this error occurs when the initial data for spacecraft position is initially given in
inertial frame and must be converted to Earth frame. This typically occurs in mission analysis
phases as the spacecraft position is computed from orbit propagation. It is however not always
the case in operational systems where the position is not provided by orbit propagation but
rather by on-board GPS system which already work in Earth frame and do know about the full
corrections. In these operational cases, the error is less important as it applies only to the
conversion of the attitude quaternions (which are typically given in inertial frame as they are
often produced by star trackers).
As Rugged delegates computation to Orekit, the full set of corrections (DUT1, pole wander, lod,
δΔε/δΔψ or δx/δy) are automatically loaded and applied. The final accuracy obtained when all EOP
are considered is at sub-millimeter level in position, and the expected difference with libraries
ignoring δΔε and δΔψ is at a few meters level, Rugged being the more accurate one.
These legacy models are very old and not recommended anymore by IERS since 2003. IERS also currently
still provides the correction for these models, but there is no guarantee they will do so indefinitely,
as they are now providing corrections with respect to newer and more accurate models. The newer frames
are based on a non-rotating origin paradigm and on different precession and nutation models (IAU-2000/2006),
which are much more accurate. The corresponding corrections (δx/δy, not to be confused with the xp/yp
pole wander) are smaller because the precession and nutation models are better than the former ones.
The much better accuracy of these new models can be seen doing the same kind of plot as before, i.e.
ignoring temporarily the IERS corrections. The plot below shows the result.
still provides the correction for these models, but there is no guarantee they will do so
indefinitely, as they are now providing corrections with respect to newer and more accurate models.
The newer frames are based on a non-rotating origin paradigm and on different precession and nutation
models (IAU-2000/2006), which are much more accurate. The corresponding corrections (δx/δy, not to be
confused with the xp/yp pole wander) are smaller because the precession and nutation models are
better than the former ones. The much better accuracy of these new models can be seen doing the same
kind of plot as before, i.e. ignoring temporarily the IERS corrections. The following figure shows the
result.
![precession/nutation error](../images/ignoring-EOP-2010.png)
The remaining error is very small, of the order of magnitude of 2 or 3 centimeters. Rugged is not limited to
the legacy MOD and TOD frames and can use the newer IERS recommended frames as well. From a user perspective,
this is completely unnoticeable as user simply selects an Earth frame as an existing predefined object by
name, and doesn't have to care about the transforms and corrections. In fact at Rugged level there is not
even a notion of precession, nutation or EOP corrections. The only interfaces used are the inertial and Earth
frames and the date. From these three elements, Orekit computes all geometrical transform, including both the
theoretical motion models and the IERS corrections, thus greatly leveraging the computation.
The remaining error is very small, of the order of magnitude of 2 or 3 centimeters. Rugged is not
limited to the legacy MOD and TOD frames and can use the newer IERS recommended frames as well. From
a user perspective, this is completely unnoticeable as user simply selects an Earth frame as an
existing predefined object by name, and doesn't have to care about the transforms and corrections.
In fact at Rugged level there is not even a notion of precession, nutation or EOP corrections. The
only interfaces used are the inertial and Earth frames names and the date. From these three elements,
Orekit computes all geometrical transform, including both the theoretical motion models and the IERS
corrections, thus greatly leveraging the computation.
One consequence of using newer precession and nutation models is that even as shown in the plot above, even
when the EOP corrections are not available yet (typically for near real-time analysis of images), it
is still possible to compute very accurately the geometry of the image.
One consequence of using newer precession and nutation models is that as shown in previous figure,
even when the EOP corrections are not available yet (typically for near real-time analysis of images),
it is still possible to compute very accurately the geometry of the image.
As a summary, Rugged may give results slightly more accurate than other geometric correction
libraries, and is compatible with both the legacy frames and the newer frames.
......@@ -213,11 +226,11 @@ Errors compensation summary
The following table summarizes the error compensations performed in the Rugged library which are not present in some other geometry correction libraries:
|-----------------------------------------------------------|-----------------------|-------------------------|:------------------------|
origin | amplitude | location | comment
δΔε and δΔψ corrections for precession and nutation models | > 3m | horizontal shift |up-to-date precession and nutation models are also available
quaternion interpolation | negligible | line-of-sight direction |the effect is important for step sizes above 1 minute
instrument position | 1.5m | along track |coupled with attitude
light time correction | 1.2m | East-West |pixel-dependent
aberration of light | 20m | along track |depends on spacecraft velocity
flat-body | 0.8m | across line-of-sight |error increases a lot for large fields of view
| origin | amplitude | location | comment
|------------------------------------------------------------|-----------------------|-------------------------|:------------------------|
| δΔε and δΔψ corrections for precession and nutation models | > 3m | horizontal shift |up-to-date precession and nutation models are also available, the error is much smaller if positions are already in Earth frame and only attitude is converted
| quaternion interpolation | negligible | line-of-sight direction |the effect is important for step sizes above 1 minute
| instrument position | 1.5m | along track |coupled with attitude
| light time correction | 1.2m | East-West |pixel-dependent, can be switched off if compensated elsewhere in the processing chain
| aberration of light | 20m | along track |depends on spacecraft velocity, can be switched off if compensated elsewhere in the processing chain
| flat-body | 0.8m | across line-of-sight |error increases a lot for large fields of view, can be switched off, but this is not recommended
src/site/markdown/downloads.md
+ 1
− 1
View file @ cea82b17
......@@ -29,7 +29,7 @@ be easily adapted if you are using one of the numerous Git graphical
user interface available or if Git is supported by you integrated
development environment:
git clone http://www.orekit.org/git/rugged
git clone https://www.orekit.org/git/rugged-main.git
Released Library versions
-------------------------
......
src/site/markdown/sources.md
+ 7
− 6
View file @ cea82b17
......@@ -30,12 +30,13 @@ Development version
The development of the Rugged project is done using the [Git](http://git-scm.com/)
source code control system. Rugged Git master repository is available online.
* you can browse it using the [Repository](https://www.orekit.org/forge/projects/rugged/repository)
tab in Rugged forge
* you can clone it anonymously with the command:
You can browse it using the [Repository](https://www.orekit.org/forge/projects/rugged/repository)
tab in Rugged forge
git clone https://www.orekit.org/git/rugged-main.git
You can clone it anonymously with the command:
** if you are a committer, you can clone it using your ssh credentials with the command:
git clone https://www.orekit.org/git/rugged-main.git
git clone ssh://git@www.orekit.org/rugged-main.git
If you are a committer, you can clone it using your ssh credentials with the command:
git clone ssh://git@www.orekit.org/rugged-main.git
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment