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

Merge branch 'master' of ssh://git@www.orekit.org/rugged-main.git 

Conflicts:
	src/site/fml/faq.fml
parents f7853754 cf6751af
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
Showing
with 221 additions and 118 deletions
core/src/main/java/org/orekit/rugged/api/FixedLOS.java
+ 3
− 3
View file @ dea7dd0a
......@@ -26,7 +26,7 @@ import org.orekit.time.AbsoluteDate;
public class FixedLOS implements TimeDependentLOS {
/** Fixed direction for los. */
final Vector3D los;
private final Vector3D los;
/** Simple constructor.
* @param los fixed direction for the line of sight
......@@ -35,8 +35,8 @@ public class FixedLOS implements TimeDependentLOS {
this.los = los;
}
/** {@inheritDoc}} */
public Vector3D getLOS(AbsoluteDate date) {
/** {@inheritDoc} */
public Vector3D getLOS(final AbsoluteDate date) {
return los;
}
......
design/rugged-design.odt deleted 100644 → 0
+ 0
− 0
View file @ f7853754
File deleted
pom.xml
+ 30
− 2
View file @ dea7dd0a
......@@ -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/building.md
+ 2
− 2
View file @ dea7dd0a
......@@ -92,7 +92,7 @@ The simplest way to use Rugged with Eclipse is to follow these steps:
* set the external libraries to JRE system library (provided by Eclipse),
Junit 4.x (provided by Eclipse), Apache Commons Math (available at
Apache Software Foundation Commons Math
[downloads page](http://commons.apache.org/proper/commons-math/download_math.cgi)),
[downloads page](http://commons.apache.org/proper/commons-math/download_math.cgi),
and Orekit (available at Orekit
[downloads page](https://www.orekit.org/forge/projects/orekit/files))
[downloads page](https://www.orekit.org/forge/projects/orekit/files)
in the libraries tab of the Configure Build Path dialog
src/site/markdown/configuration.md 0 → 100644
+ 42
− 0
View file @ dea7dd0a
<!--- Copyright 2013-2014 CS Systèmes d'Information
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
Configuration
=============
As Rugged relied on Orekit for the frames computation, Orekit
must be properly initialized for Rugged to run.
The simplest way to configure is to first retrieve the example orekit-data.zip
file from Orekit [files](https://www.orekit.org/forge/projects/orekit/files) section
and to unzip it in a known fixed location on your computer (let's assume it is on
your home folder, and it creates an orekit-data subfolder there).
Then near the start of your main program, and before Orekit is called for the
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.getInstance().addProvider(new DirectoryCrawler(orekitData));
This is sufficient to start working.
Note that some of the data in the orekit-data folder needs to be updated,
typically the UTC-TAI.history file, which is updated about once every 18 months
by IERS, and the files in the Earth-Orientation-Parameters folder which are updated
regularly by IERS. The update frequency depends on which file you use.
The data provided in the example archive from Orekit site are example only and are
not kept up to date. The real operational data are live, and remain under the
responsibility of the user.
\ No newline at end of file
src/site/markdown/contact.md
+ 14
− 14
View file @ dea7dd0a
......@@ -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!
......@@ -44,13 +45,12 @@ Administrative contact
If you want to discuss with the space division staff at CS Systèmes d'Information,
please use the following address:
|:---------------------------------------------------------------------|
| CS Systèmes d'Information |
| BU E-space & Geoinformation |
| parc de la plaine - 5 rue Brindejonc des Moulinais |
| BP 15872 |
| 31506 Toulouse CEDEX 5 |
| FRANCE |
| |
| phone: +33 5-61-17-66-66 (ask for Luc Maisonobe or Aude Espesset) |
| fax: +33 5-61-34-84-15 |
CS Systèmes d'Information
BU E-space & Geoinformation
parc de la plaine - 5 rue Brindejonc des Moulinais
BP 15872
31506 Toulouse CEDEX 5
FRANCE
phone: +33 5-61-17-66-66 (ask for Luc Maisonobe or Aude Espesset)
fax: +33 5-61-34-84-15
src/site/markdown/design/overview.md
+ 18
− 18
View file @ dea7dd0a
......@@ -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 @ dea7dd0a
......@@ -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 @ dea7dd0a
......@@ -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/guidelines.md
+ 54
− 36
View file @ dea7dd0a
......@@ -96,75 +96,93 @@ configuration. A few of these rules are displayed below. The complete
definition is given by the checkstyle configuration file in the project
root directory.
*header rule*
: all source files start with the Apache license header,
* *header rule*
all source files start with the Apache license header,
*indentation rules*
: no tabs, 4 spaces indentation, no indentation for case statements,
* *indentation rules*
no tabs, 4 spaces indentation, no indentation for case statements,
*operators wrapping rules*
: lines are wrapped after operators (unlike Sun),
* *operators wrapping rules*
lines are wrapped after operators (unlike Sun),
*whitespace rules*
: operators are surrounded by spaces, method parameters open parenthesis
* *whitespace rules*
operators are surrounded by spaces, method parameters open parenthesis
is not preceded by space, lines do not end with white space,
*curly brace rules*
: open curly brace are at end of line, with the matching closing curly brace
* *curly brace rules*
open curly brace are at end of line, with the matching closing curly brace
aligned with the start of the corresponding keyword (_if_, _for_,
_while_, _case_ or _do_),
*encoding rules*
: characters encoding is _UTF8_, the git property _core.autocrlf_ should be
* *encoding rules*
characters encoding is _UTF8_, the git property _core.autocrlf_ should be
set to _input_ on Linux development machines and to _true_ on Windows
development machines (to ensure proper conversion on all operating systems),
*naming rules*
: classes names begin with upper case, instance methods and fields
* *naming rules*
classes names begin with upper case, instance methods and fields
names begin with lower case, class fields are all upper case with
words separated by underscores,
*ordering rules*
: class variables come first, followed by instance variables, followed
* *ordering rules*
class variables come first, followed by instance variables, followed
by constructors, and followed by methods, public modifiers come first,
followed by protected modifiers followed by private modifiers,
*javadoc rules*
: all elements have complete javadoc, even private fields and methods
* *javadoc rules*
all elements have complete javadoc, even private fields and methods
(there are some rare exceptions, in case of code translated from
the fortran language and models with huge parameters sets),
*robustness rules*
: switch/case construct have a default argument, even when all possible
* *robustness rules*
switch/case construct have a default argument, even when all possible
cases are already handled, as many classes as possible are immutable,
*miscellaneous rules*
: _star_ imports are forbidden, parameters and local variables are final
* *miscellaneous rules*
_star_ imports are forbidden, parameters and local variables are final
wherever possible.
Design Rules
------------
*coverage* (validation)
: seek for a line test coverage of at least 80% (more is better)
* *coverage* (validation)
seek for a line test coverage of at least 80% (more is better)
* *findbugs* (robustness)
fix _all_ errors and warnings found by findbugs
*findbugs* (robustness)
: fix _all_ errors and warnings found by findbugs
* *no runtime assumptions* (robustness)
*no runtime assumptions* (robustness)
: do not make assumptions on the runtime environment of applications using Rugged
do not make assumptions on the runtime environment of applications using Orekit
(they may be embedded with no console, no possible user interaction, no network,
no writable file system, no stoppable main program, have memory constraints,
time constraints, be run in different linguistic contexts ...)
*simplicity* (maintainability)
: follow Occam's razor principle or its declination in computer science: KISS (Keep It Simple, Stupid)
* *simplicity* (maintainability)
follow Occam's razor principle or its declination in computer science: KISS (Keep It Simple, Stupid)
* *balanced design* (efficiency)
seek efficiency, but do not overstep robustness and maintainability
* *immutable objects* (robustness, maintainability)
*balanced design* (efficiency)
: seek efficiency, but do not overstep robustness and maintainability
use immutable objects as much as possible
*immutable objects* (robustness, maintainability)
: use immutable objects as much as possible
* *checkstyle* (style)
*checkstyle* (style)
: fix _all_ errors and warnings found by checkstyle
fix _all_ errors and warnings found by checkstyle
src/site/markdown/sources.md
+ 7
− 6
View file @ dea7dd0a
......@@ -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 http://www.orekit.org/git/rugged
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.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
src/site/site.xml
+ 1
− 0
View file @ dea7dd0a
......@@ -29,6 +29,7 @@
<item name="Overview" href="/index.html" />
<item name="Getting the sources" href="/sources.html" />
<item name="Building" href="/building.html" />
<item name="Configuration" href="/configuration.html" />
<item name="FAQ" href="/faq.html" />
<item name="License" href="/license.html" />
<item name="Downloads" href="/downloads.html" />
......
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