Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found

Target

Select target project
  • orekit/rugged
  • sdinot/rugged
  • yzokras/rugged
  • youngcle/rugged-mod
4 results
Show changes
Hide whitespace changes
Inline Side-by-side
Showing
with 793 additions and 127 deletions
src/site/markdown/downloads.md → src/site/markdown/downloads.md.vm
View file @ acf902ea
<!--- Copyright 2013-2016 CS Systèmes d'Information
<!--- Copyright 2013-2022 CS GROUP
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.
......@@ -12,14 +12,14 @@
limitations under the License.
-->
Downloads
=========
<a name="top"></a>
Development Library version
---------------------------
# Downloads
<h2>Development Library version</h2>
The development version of the Rugged library is always available to
download from our version control system. We use [ Git](http://git-scm.com/)
download from our version control system. We use [Git](http://git-scm.com/ "Git homepage")
as our SCM. The anonymous read access to our Git repository allows users who
need the latest features and the latest bug fixes to get them even before an
official release.
......@@ -29,10 +29,9 @@ 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 https://www.orekit.org/git/rugged-main.git
git clone -b develop https://gitlab.orekit.org/orekit/rugged.git
Released Library versions
-------------------------
<h2>Released Library versions</h2>
Rugged is provided both in several packaging systems. You can pick up
the one that better suits your needs. Source packages are the most complete
......@@ -44,44 +43,56 @@ with groupID org.orekit and artifactId rugged so maven
internal mechanism will download automatically all artifacts and dependencies
as required.
| package | link |
|----------|-----------------------------------------------------------------------------------------------------------|
| source | [rugged-1.0-sources.zip](https://www.orekit.org/forge/attachments/download/592/rugged-1.0-sources.zip) |
| binary | [rugged-1.0.jar](https://www.orekit.org/forge/attachments/download/593/rugged-1.0.jar) |
| javadoc | [rugged-1.0-javadoc.jar](https://www.orekit.org/forge/attachments/download/594/rugged-1.0-javadoc.jar) |
version 1.0 downloads (release date: 2016-02-10)
#set ( $versions = {"3.0": "2022-07-05", "2.2": "2020-07-31", "2.1": "2019-03-14", "2.0": "2017-12-19", "1.0": "2016-02-10"} )
#foreach( $version in $versions.entrySet() )
| package | link |
|----------|---------------------------------------------------------------------------------------------------------------------------------------|
| source | [rugged-${version.key}-sources.jar](https://search.maven.org/remotecontent?filepath=org/orekit/rugged/${version.key}/rugged-${version.key}-sources.jar) |
| binary | [rugged-${version.key}.jar](https://search.maven.org/remotecontent?filepath=org/orekit/rugged/${version.key}/rugged-${version.key}.jar) |
| javadoc | [rugged-${version.key}-javadoc.jar](https://search.maven.org/remotecontent?filepath=org/orekit/rugged/${version.key}/rugged-${version.key}-javadoc.jar) |
version ${version.key} downloads (release date: ${version.value})
## Data
#end
For convenience, a zip archive containing some configuration data is
available for download. Similar files can be custom made by users with updated data.
Configuring data loading is explained in the configuration page For a start, the simplest configuration
is to download the orekit-data.zip file from the download page, to unzip it anywhere you want, note the
path of the orekit-data folder that will be created and add the following lines at the start of
your program:
<h2>Data</h2>
For convenience, a zip archive containing some configuration data is available
for download. Similar files can be custom made by users with updated data.
Configuring data loading is explained in the configuration page. For a start,
the simplest configuration is to download the
[orekit-data-master.zip](https://gitlab.orekit.org/orekit/orekit-data/-/archive/master/orekit-data-master.zip)
file from the forge, to unzip it anywhere you want, rename the `orekit-data-master` folder that will be created
into `orekit-data` and add the following lines at the start of your program:
File orekitData = new File("/path/to/the/folder/orekit-data");
DataProvidersManager manager = DataProvidersManager.getInstance();
DataProvidersManager manager = DataContext.getDefault().getDataProvidersManager();
manager.addProvider(new DirectoryCrawler(orekitData));
This file contents is:
This file contains the following data sets. Note that the data is updated only
from time to time, so users must check by themselves they cover the time range
needed for their computation.
* leap seconds data up to end of 2016,
* leap seconds data,
* IERS Earth orientation parameters from 1973 to mid 2016
with predicted date to fall 2016 for some parameters (both IAU-1980 and IAU-2000),
* IERS Earth orientation parameters from 1973 (both IAU-1980 and IAU-2000),
* Marshall Solar Activity Futur Estimation from 1999 to mid 2016,
* Marshall Solar Activity Future Estimation from 1999,
* DE 430 planetary ephemerides from 1990 to 2069,
* JPL DE 430 planetary ephemerides from 1990 to 2069,
* Eigen 06S gravity field,
* FES 2004 ocean tides model.
There are no guarantees that this file will be available indefinitely or that its
content will be updated. It should be considered as a simple configuration example.
Users are encouraged to set up their own configuration data.
The file is available by following this link: [orekit-data.zip](https://www.orekit.org/forge/attachments/download/610/orekit-data.zip).
The file is available by following the
[download](https://gitlab.orekit.org/orekit/orekit-data/-/archive/master/orekit-data-master.zip)
link in the project dedicated to Orekit Data in the forge.
[Top of the page](#top)
src/site/markdown/faq.md
View file @ acf902ea
<!--- Copyright 2013-2016 CS Systèmes d'Information
<!--- Copyright 2013-2022 CS GROUP
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
......@@ -12,13 +12,26 @@
limitations under the License.
-->
References
----------
<a name="top"></a>
# Frequently Asked Questions (FAQ)
## References
### Has Rugged already been used?
Yes. Rugged is used operationally in the Image Processing Facility
of the Sentinel 2 ESA mission, which was launched in June 2015.
Yes, it has been used in successful operational missions.
Rugged is used operationally in the Image Processing Facility
of the Sentinel 2 European Space Agency (ESA) mission, which was launched in June 2015.
Rugged is used in the frame of ESA Scientific Exploitation of Operational Missions (SEOM),
to calculate topographic shadow masks for Sentinel 2 products.
Rugged has been used to validate Airbus Defence and Space (ADS) geolocation library.
Rugged has been used as a Research Library by the French Space Agency (CNES) for
refinement studies for VHR push broom sensors (Pleiades).
### Is Rugged validated?
......@@ -39,41 +52,43 @@ configuring Rugged to use the same legacy models (these legacy models like for e
TOD and MOD frames are available for consistency with existing systems).
Installation
------------
## Installation
### What are the dependencies for Rugged?
Rugged relies on the Orekit space flight dynamics library and on
Hipparchus mathematical libraries. Both libraries are free
Rugged relies on the [Orekit](https://www.orekit.org/ "Orekit homepage") space flight dynamics library and on
[Hipparchus](https://hipparchus.org/ "Hipparchus homepage") mathematical libraries. Both libraries are free
software libraries distributed under the terms of the Apache Software
License version 2.0.
Runtime errors
--------------
## Runtime errors
### I get an error "no IERS UTC-TAI history data loaded" (or something similar in another language). What does it mean?
This error is probably the most frequent one, or at least it's the first one new users encounter.
This error is probably *the* most frequent one, or at least it's the first one new users encounter.
Rugged relies on the Orekit library to perform all space flight related computation (typically
frames transforms). This library in turn needs some external data to be loaded in order to run.
This includes UTC-TAI history for leap seconds handling, Earth Orientation Parameters for
transforms to and from Earth fixed frames, or planetar ephemerides for Sun direction, for example.
transforms to and from Earth fixed frames, or planetary ephemerides for Sun direction, for example.
The error message "no IERS UTC-TAI history data loaded" means the UTC-TAI history file which is used for leap
seconds management was not found. As leap seconds are used each time a UTC date is used, this message is
often seen very early and is the first one unsuspecting users experience. It often means the user forgot
to configure Orekit to load data.
to configure Orekit to load data. Orekit supports by default either the IERS UTC-TAI.history file or the
USNO tai-utc.dat file. If either file is found in the Orekit configuration, it will be automatically loaded
and the message should not appear.
Configuring data loading is explained in the configuration page For a start, the simplest configuration
is to download the orekit-data.zip file from the Orekit project download page, to unzip it anywhere you
want, note the path of the orekit-data folder that will be created and add the following lines at the start
of your program:
Configuring data loading is explained in the configuration page. For a start, the simplest configuration
is to download the [orekit-data-master.zip](https://gitlab.orekit.org/orekit/orekit-data/-/archive/master/orekit-data-master.zip)
file from the forge, to unzip it anywhere you want, rename the `orekit-data-master` folder that will be created
into `orekit-data` and add the following lines at the start of your program:
File orekitData = new File("/path/to/the/folder/orekit-data");
DataProvidersManager manager = DataProvidersManager.getInstance();
DataProvidersManager manager = DataContext.getDefault().getDataProvidersManager();
manager.addProvider(new DirectoryCrawler(orekitData));
Using a folder allows one to change the data in it after the initial download, e.g., adding new EOP files as they
are published by IERS.
are published by IERS. Updating the content of the orekit-data remains the responsibility of the user.
[Top of the page](#top)
src/site/markdown/guidelines.md
View file @ acf902ea
<!--- Copyright 2013-2016 CS Systèmes d'Information
<!--- Copyright 2013-2022 CS GROUP
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.
......@@ -12,13 +12,13 @@
limitations under the License.
-->
Development Guidelines
======================
<a name="top"></a>
# Development Guidelines
The following guidelines are used for Rugged development.
Development
-----------
## Development
Rugged is an intermediate level library. It may be used in very different
contexts which cannot be foreseen, from quick studies up to critical
......@@ -34,7 +34,7 @@ operations. The main driving goals are the following ones:
The first goal, validation, implies tests must be as extensive as possible.
They should include realistic operational cases but also contingency cases.
The [jacoco](http://www.eclemma.org/jacoco/) tool must be used to
The [jacoco](http://www.eclemma.org/jacoco/ "Jacoco homepage") tool must be used to
monitor test coverage. A very high level of coverage is desired. We do not
set up mandatory objective figures, but only guidelines here. However,a 60%
line coverage would clearly not be acceptable at all and 80% would be considered
......@@ -44,7 +44,7 @@ The second goal, robustness, has some specific implications for a low level
component like Rugged. In some sense, it can be considered an extension of the
previous goal as it can also be improved by testing. It can also be improved
by automatic checking tools that analyze either source code or binary code. The
[findbugs](http://findbugs.sourceforge.net/) tool is already configured for
[spotbugs](https://spotbugs.github.io/ "Spotbugs homepage") tool is already configured for
automatic checks of the library using a maven plugin.
This is however not sufficient. A library is intended to be used by applications
......@@ -84,13 +84,60 @@ difficult to catch bugs are caused by mutable objects that are changed in some d
buried code and have an impact on user code that forgot to perform a defensive copy.
Orbits, dates, vectors, and rotations are all immutable objects.
Style Rules
-----------
## Source Control Management
The source code control management system used is [Git](http://git-scm.com/ "Git homepage"). The
main Rugged repository is located at [https://gitlab.orekit.org/orekit/rugged.git](https://gitlab.orekit.org/orekit/rugged.git).
Starting after version 2.0, the branch management workflow is adapted from
both [git flow](http://nvie.com/posts/a-successful-git-branching-model/) and
from the [Orfeo ToolBox Workflow](https://wiki.orfeo-toolbox.org/index.php/Git#Workflow "OTB workflow").
It is the same as chosen for Orekit.
![Rugged git workflow](./images/rugged-git-flow.png)
This implies that development occurs on a develop branch only.
Developers create feature branches, and merge them on the develop
branch when ready. The develop branch should always be functional
so people wanting to be on the bleeding edge can use it (for example
to create nightly builds or to prepare their application for upcoming
features before the official release).
In order to improve traceability, when a feature branch is merged into
develop, it should use
git merge ---no-ff
the --no-ff flag prevents fast-forward so the history makes it clear there
was a feature branch at this point.
Feature branches are temporary, they are deleted when they are not useful anymore.
Feature branches may be present only in one developer workspace and never appear
in the main repository, however, they may also be pushed on the main repository
if the developer wants to share work or needs community feedback.
When a release is desired, a dedicated branch should be created, with a name
following the pattern release-x.y. These branches are created from the
develop branch. When the release is ready, the branch is merged both into the
master branch and into the develop branch. Once a release branch has been set
up, it will remain. This allows users relying on this specific version to be
able to retrieve the fixes published afterward (i.e. x.y.1, x.y.2...).
After a release has been published and pushed to master, it may be necessary
to publish an urgent bugfix if a serious problem in the released version is
found. Short-lived bugfix branches that are created directly from master are
devoted to this. These bugfix branches are merged back into master and develop.
The master branch always refer to the latest stable release performed. No
direct work is done on this branch. It is updated only by merging either
release branches or bugfix branches branches to it.
## Style Rules
For reading ease and consistency, the existing code style should be
preserved for all new developments. The rules are common ones, inherited
mainly from the Sun [Code Conventions for the Java
Programming Language](http://java.sun.com/docs/codeconv/) guide style and
mainly from the Sun Code Conventions for the Java Programming Language guide style and
from the default [checkstyle](http://checkstyle.sourceforge.net/) tool
configuration. A few of these rules are displayed below. The complete
definition is given by the checkstyle configuration file in the project
......@@ -99,70 +146,69 @@ root directory.
* *header rule*
all source files start with the Apache license header,
* *indentation rules*
no tabs, 4 spaces indentation, no indentation for case statements,
* *operators wrapping rules*
lines are wrapped after operators (unlike Sun),
* *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
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
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
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
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
(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
cases are already handled, as many classes as possible are immutable,
* *miscellaneous rules*
_star_ imports are forbidden, parameters and local variables are final
wherever possible.
Design Rules
------------
## Design Rules
* *coverage* (validation)
seek for a line test coverage of at least 80% (more is better)
* *findbugs* (robustness)
* *spotbugs* (robustness)
fix _all_ errors and warnings found by findbugs
fix _all_ errors and warnings found by spotbugs
* *no runtime assumptions* (robustness)
......@@ -186,3 +232,6 @@ Design Rules
* *checkstyle* (style)
fix _all_ errors and warnings found by checkstyle
[Top of the page](#top)
src/site/markdown/index.md
View file @ acf902ea
<!--- Copyright 2013-2016 CS Systèmes d'Information
<!--- Copyright 2013-2022 CS GROUP
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
......@@ -12,12 +12,13 @@
limitations under the License.
-->
Overview
========
<a name="top"></a>
Rugged is a sensor-to-terrain mapping tool which takes into account Digital Elevation Models (DEM)
# Overview
Rugged is a sensor-to-terrain mapping tool which takes into account Digital Elevation Models (DEM)
in its line of sight computation. It is a free software
intermediate-level library written in Java and implemented as an add-on for Orekit.
intermediate-level library written in Java and implemented as an add-on for [Orekit](https://www.orekit.org/ "Orekit homepage").
![Earth_FlatVsRugged.gif](./images/Earth_FlatVsRugged.gif)
......@@ -36,18 +37,19 @@ Overview
Direct and inverse location can be used to perform full ortho-rectification
of images and correlation between sensors observing the same area.
Features
--------
## Features
* Direct/inverse location
* can support several types of Digital Elevation Models, including user-provided models
* Refinement
* Can support several types of Digital Elevation Models, including user-provided models
* several intersection models algorithms available
* Several intersection models algorithms available
* can propagate orbit by itself for preliminary mission analysis or data generation
* Can propagate orbit by itself for preliminary mission analysis or data generation
* can propagate attitude by itself for preliminary mission analysis or data generation
* Can propagate attitude by itself for preliminary mission analysis or data generation
* *very* fast
......@@ -56,7 +58,7 @@ Features
* Mathews, Herring, Buffett (2002)
* Capitaine (2006)
* complete set of corrections applied for greater accuracy
* Complete set of corrections applied for greater accuracy
* δΔψ, δΔε on precession nutation (about 3m correction since 2013, steadily increasing)
* ΔUT₁, lod on proper rotation (can theoretically reach up to 400m)
* u, v pole wander (polhody), (about 15m correction)
......@@ -64,32 +66,25 @@ Features
* aberration of light correction (about 20m)
* line-of-sight curvature in geodetic coordinates,
(0m at nadir, 10m at 30° dive angle, hundreds of meters for skimming los)
* refraction not available in early 2016, but expected to be added soon
* atmospheric refraction
* not limited to Earth
* Not limited to Earth
* highly portable (Linux, Windows, MacOSX, ...)
* Highly portable (Linux, Windows, MacOSX, ...)
* Localized in several languages
* Danish
* English
* French
* Galician
* German
* Italian
* Norwegian
* Romanian
* Spanish
Free software
-------------
## Free software
Rugged is freely available both in source and binary formats, with all related
documentation and tests.
......@@ -101,12 +96,20 @@ any application, free or not. There are no strings attached to your own code.
Everybody is encouraged to use Rugged as a common intermediate level layer to improve
interoperability in space systems.
Maintained library
------------------
## Maintained library
Rugged has been in development since 2014 inside [CS Systèmes
d'Information](http://www.c-s.fr/) and is still used and maintained by its dual teams
Rugged has been in development since 2014 inside [CS GROUP](https://www.csgroup.eu/ "CS GROUP homepage")
and is still used and maintained by its dual teams
of space dynamics and image processing experts.
Rugged is used for image processing of the Sentinel 2 mission at European Space
Agency (ESA).
Agency (ESA), as well as in the frame of ESA Scientific Exploitation of Operational Missions (SEOM),
to calculate topographic shadow masks for Sentinel 2 products.
Rugged has been used to validate Airbus Defence and Space (ADS) geolocation library.
Rugged has been also used as a Research Library by the French Space Agency (CNES) for refinement studies for VHR push broom sensors (Pleiades).
Rugged is used for study purposes inside CS GROUP.
[Top of the page](#top)
src/site/markdown/release-guide.md 0 → 100644
View file @ acf902ea
# Rugged Release Guide
This release guide is largely inspired from [Hipparchus Release
Guide](https://www.hipparchus.org/release-guide.html) and [Orekit Release Guide](https://www.orekit.org/site-orekit-development/release-guide.html). It lists the steps that
have been used in the past to release a new version of Rugged. When in doubt
ask the experts: Sébastien Dinot <sebastien.dinot@csgroup.eu> for website questions
and Luc Maisonobe <luc.maisonobe@csgroup.eu> for everything else.
## Prerequisites
1. Obtain private key of the Rugged Signing Key, key id:
`9A928E5485FBC44A2A4F9C2E9128808ECB6C9DED`
2. Register for account on OSSRH and associate it with the Rugged project, see:
https://central.sonatype.org/pages/ossrh-guide.html
If you need help with either, ask on the [development section of the Rugged
forum](https://forum.orekit.org/c/rugged-development/).
Once you have a SonaType OSS account, the corresponding credentials must be set
in the `servers` section of your `$HOME/.m2/settings.xml` file, using an id of
`ossrh`:
<servers>
<server>
<id>ossrh</id>
<username>the user name to connect to the OSS site</username>
<password>the encrypted password</password>
</server>
</servers>
Use `mvn -ep` to generate an encrypted password.
## Install Graphviz
[Graphviz (dot)](https://graphviz.org) is used to generated diagrams of
the technical documentation (static site).
## Verify the status of develop branch
Before anything, check on the [continuous integration
site](https://sonar.orekit.org/dashboard?id=org.orekit%3Arugged) that everything is fine on
develop branch:
* All tests pass;
* Code coverage is up to the requirements;
* There are no bugs, vulnerabilities or code smells.
If not, fix the warnings and errors first !
It is also necessary to check on the [Gitlab CI/CD](https://gitlab.orekit.org/orekit/rugged/pipelines)
that everything is fine on develop branch (i.e. all stages are passed).
## Prepare Git branch for release
Release will be performed on a dedicated branch, not directly on master or
develop branch. So a new branch must be created as follows and used for
everything else:
git branch release-X.Y
git checkout release-X.Y
## Update maven plugins versions
Release is a good opportunity to update the maven plugin versions. They are all
gathered at one place, in a set of properties in `rugged/pom.xml`, for instance:
<rugged.spotbugs-maven-plugin.version>4.0.4</rugged.spotbugs-maven-plugin.version>
<rugged.jacoco-maven-plugin.version>0.8.5</rugged.jacoco-maven-plugin.version>
<rugged.maven-assembly-plugin.version>3.1.1</rugged.maven-assembly-plugin.version>
...
You can find the latest version of the plugins using the search feature at
[http://search.maven.org/#search](http://search.maven.org/#search). The
properties name all follow the pattern `rugged.some-plugin-name.version`, the
plugin name should be used in the web form to check for available versions.
Beware that in some cases, the latest version cannot be used due to
incompatibilities. For example when a plugin was not recently updated and
conflicts appear with newer versions of its dependencies.
Beware also that some plugins use configuration files that may need update too.
This is typically the case with `maven-checkstyle-plugin` and
`spotbugs-maven-plugin`. The `/checkstyle.xml` and `/spotbugs-exclude-filter.xml` files may need to be checked.
Before committing these changes, you have to check that everything works. So
run the following command:
mvn clean
LANG=C mvn -Prelease site
If something goes wrong, either fix it by changing the plugin configuration or
roll back to an earlier version of the plugin.
Browse the generated site starting at page `target/site/index.html` and check
that everything is rendered properly. You may also check the contents of the pages.
When everything runs fine and the generated site is OK, then you can commit the
changes:
git add rugged/pom.xml rugged/checkstyle.xml rugged/spotbugs-exclude-filter.xml
git commit -m "Updated maven plugins versions."
## Updating changes.xml
Finalize the file `src/changes/changes.xml` file.
The release date and description, which are often only set to `TBD` during
development, must be set to appropriate values. The release date at this step
is only a guess one or two weeks in the future, in order to take into account
the 5 days release vote delay.
Replace the `TBD` description with a text describing the version released:
state if it is a minor or major version, list the major features introduced by
the version etc (see examples in descriptions of former versions).
Commit the `changes.xml` file.
git add src/changes/changes.xml
git commit -m "Updated changes.xml for official release."
## Updating documentation
Several files must be updated to take into account the new version:
| file name | usage | required update |
|-------------------------------------|----------------------------|--------------------------------------------------------------------------------------------------------|
| `src/site/markdown/index.md` | site home page | Update the text about the new features (see changes from **changes.xml**) |
| `src/site/markdown/downloads.md.vm` | downloads links | Declare the new versions, don't forget the date |
Once the files have been updated, commit the changes:
git add src/site/markdown/*.md
git commit -m "Updated documentation for the release."
## Change library version number
The `pom.xml` file contains the version number of the library. During
development, this version number has the form `X.Y-SNAPSHOT`. For release, the
`-SNAPSHOT` part must be removed.
Commit the change:
git add pom.xml
git commit -m "Dropped -SNAPSHOT in version number for official release."
## Check the JavaDoc
Depending the JDK version (Oracle, OpenJDK, etc), some JavaDoc warnings can be present.
Make sure there is no JavaDoc warnings by running the following command:
mvn javadoc:javadoc
If possible, run the above command with different JDK versions.
## Tag and sign the git repository
When all previous steps have been performed, the local git repository holds the
final state of the sources and build files for the release. It must be tagged
and the tag must be signed. Note that before the vote is finished, the tag can
only signed with a `-RCx` suffix to denote Release Candidate. The final tag
without the `-RCx` suffix will be put once the vote succeeds, on the same
commit (which will therefore have two tags). Tagging and signing is done using
the following command, with `-RCn` replaced with the Release Candidate number:
git tag X.Y-RCn -s -u 9A928E5485FBC44A2A4F9C2E9128808ECB6C9DED -m "Release Candidate n for version X.Y."
The tag should be verified using command:
git tag -v X.Y-RCn
## Pushing the branch and the tag
When the tag is ready, the branch and the tag must be pushed to Gitlab so
everyone can review it:
git push --tags origin release-X.Y
## Static site (technical documentation)
The static site is generated locally using:
mvn clean
LANG=C mvn site
The official site is automatically updated on the hosting platform when work is
merged into branches `develop`, `release-*` or `master`.
## Generating signed artifacts
When these settings have been set up, generating the artifacts is done by
running the following commands:
mvn deploy -DskipStagingRepositoryClose=true -Prelease
During the generation, maven will trigger gpg which will ask the user for the
pass phrase to access the signing key. If maven didn’t prompt to you, you have to
add `-Dgpg.passphrase=[passphrase]`
Once the commands ends, log into the SonaType OSS site
[https://oss.sonatype.org/](https://oss.sonatype.org/) and check the staging
repository contains the expected artifacts with associated signatures and
checksums:
- rugged-X.Y.pom
- rugged-X.Y.jar
- rugged-X.Y-sources.jar
- rugged-X.Y-javadoc.jar
The signature and checksum files have similar names with added extensions `.asc`,
`.md5` and `.sha1`.
Sometimes, the deployment to Sonatype OSS site also adds files with double extension
`.asc.md5` and `.asc.sha1`, which are in fact checksum files on a signature file
and serve no purpose and can be deleted.
Remove `rugged-X.Y.source-jar*` since they are duplicates of the
`rugged-X.Y-sources.jar*` artifacts. Then click the “Close” button.
## Update Rugged version in Rugged test website
One edit needs to be made to the Rugged website before calling the vote. Fetch the current code:
git clone https://gitlab.orekit.org/orekit/website-2015
Switch to `develop` branch and edit `_data/rugged/versions.yml` by adding the new version X.Y
to the list.
Once the modification pushed to develop branch, the [test website](https://test.orekit.org/rugged) will be updated
## Calling for the vote
Everything is now ready so the developers and PMC can vote for the release.
Create a post in the [Rugged development category of the forum](https://forum.orekit.org/c/rugged-development/)
with a subject line of the form:
[VOTE] Releasing Rugged X.Y from release candidate n
and content of the form:
This is a VOTE in order to release version X.Y of the Rugged library.
Version X.Y is a maintenance release.
Highlights in the X.Y release are:
- feature 1 description
...
- feature n description
The release candidate n can be found on the GitLab repository as
tag X.Y-RCn in the release-X.Y branch:
<https://gitlab.orekit.org/orekit/rugged/tree/X.Y-RCn>
The release notes can be read here:
<https://test.orekit.org/site-rugged-X.Y/changes-report.html>
Maven artifacts are available at
<https://oss.sonatype.org/content/repositories/orgorekit-xxxx/>
The votes will be tallied in 120 hours for now, on 20yy-mm-ddThh:mm:00Z
(this is UTC time).
You should also ping PMC members so they are aware of the vote. Their
vote is essential for a release as per project governance.
## Failed vote
If the vote fails, the maven artifacts must be removed from OSS site by
dropping the repository. Then a new release candidate must
be created, with a new number, a new tag and new artifacts. Another vote is
needed for this new release candidate. So make the necessary changes and then
start from the “Tag and sign the git repository” step.
## Successful vote
When the vote for a release candidate succeeds, follow the steps below to
publish the release.
## Tag release version
As the vote passed, a final signed tag must be added to the succeeding release
candidate, verified and pushed:
git tag X.Y -s -u 9A928E5485FBC44A2A4F9C2E9128808ECB6C9DED -m "Version X.Y."
git tag -v X.Y
git push --tags
## Merge release branch into master
Merge the release branch into the `master` branch to include any changes made.
git checkout master
git merge --no-ff release-X.Y
Then commit and push.
## Merge master branch into develop
Merge the `master` branch into the `develop` branch to include any changes made.
git checkout develop
git merge --no-ff master
Then update the version number to prepare for the next development cycle:
- edit the pom.xml to update version to a SNAPSHOT,
- make space in the `/src/changes/changes.xml` file for new changes.
Then commit and push.
## Publish maven artifacts
The maven artifacts must be published using OSS site to release the repository.
Select the Rugged repository in "Staging Repositories" and click the “Release”
button in [Nexus Repository Manager](https://oss.sonatype.org/).
## Upload to Gitlab
Navigate to Projects > Rugged > Repository > Tags. Find the X.Y tag and
click the edit button to enter release notes. Use the **path** in the [Nexus
repository](https://packages.orekit.org/#browse/browse:maven-releases:org%2Forekit%2Frugged) to
set the artifacts in the release notes.
- rugged-X.Y.jar
- rugged-X.Y-sources.jar
- rugged-X.Y-javadoc.jar
Navigate to Projects > Rugged > Project Overview > Releases and make sure it looks nice.
## Synchronize the Github mirror
To enhance the visibility of the project, [a mirror](https://github.com/CS-SI/Rugged) is maintained on Github.
The releases created on Gitlab are not automatically pushed on this mirror.
They have to be declared manually to make visible the vitality of Rugged.
1. Login to Github
2. Go to the [Rugged releases](https://github.com/CS-SI/Rugged/releases) page
3. Click on the [Draft a new release](https://github.com/CS-SI/Rugged/releases) button
4. In the "Tag version" field of the form and in the "Release title" field, enter the tag of the release to be declared
5. Describe the release as it has been done on Gitlab
6. Click on "Publish release"
Github automically adds two assets (zip and tarball archives of the tagged source code).
## Update Rugged website
Several edits need to be made to the Rugged website after the vote.
Edit `download/.htaccess` and replace the URLs of the 3 Rugged artifacts
with the ones used to create the release notes.
Edit `_layouts/home_rugged.html` and edit the text of the button to use the new version.
Edit `rugged/overview.html` with the new Orekit and Hipparchus versions. Don't forget to update the
rugged/img/rugged-architecture.png image with the new dependencies.
Create a new post for the release in `_post/` using as template a previous Rugged post (in order to be published in the Rugged News page). To be noticed the `--future` option is needed to see a post in the future, otherwise `jekyll serve` will ignore it !
Run:
jekyll serve --future
and make sure the website looks nice. View it on http://localhost:4000/
## Close X.Y milestone
In Gitlab, navigate to Projects > Rugged > Issues > Milestones.
Click “Close Milestone” for the line corresponding to the release X.Y.
## Announce release
The last step is to announce the release by creating a post in the
[Rugged announcements category of the forum](https://forum.orekit.org/c/rugged-announcements/)
with a subject line of the form:
Rugged X.Y released
and content of the form:
The Rugged team is pleased to announce the release of Rugged version X.Y.
This is a minor/major version, including both new features and bug fixes.
The main changes are:
- feature 1 description
...
- feature n description
This version depends on Orekit X.x and Hipparchus Y.y.
For complete release notes please see:
https://www.orekit.org/site-rugged-X.Y/changes-report.html
The maven artifacts are available in maven central.
The source and binaries can be retrieved from the forge releases page:
https://gitlab.orekit.org/orekit/rugged/-/releases
src/site/markdown/sources.md
View file @ acf902ea
<!--- Copyright 2013-2016 CS Systèmes d'Information
<!--- Copyright 2013-2022 CS GROUP
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.
......@@ -12,31 +12,44 @@
limitations under the License.
-->
Getting the sources
===================
<a name="top"></a>
# Getting the sources
Released versions
-----------------
## Released versions
In order to get the source for officially released versions, go to the
[Files](https://www.orekit.org/forge/projects/rugged/files) tab in Rugged
forge and select one of the rugged-{module}-x.y-src.zip files. The module
part is the module (you need at least the core module, but other modules
may be interesting for you too). The x.y part in the name specifies the version.
[Release page](https://gitlab.orekit.org/orekit/rugged/tags) in Rugged
forge and select one of the `rugged-x.y-sources.zip` files. The `x.y` part in the name
specifies the version.
If this is the first time you download the library and
you have not yet set up your own data set with UTC-TAI history, JPL ephemerides,
IERS Earth Orientation Parameters ... you may want to also download the
`orekit-data.zip` file which is an example file suitable for a quick start (see
[configuration](./configuration.html) for further reading about data configuration).
It is also possible to retrieve published versions from the Git repository
(see next section below), if retrieving either release-x.y branches or the
master branch.
## Development version
Development version
-------------------
The development of the Rugged project is done using the [Git](http://git-scm.com/ "Git homepage")
source code control system. Rugged Git master repository is available online.
The latest developments are in the develop branch. This is the one you want to retrieve
if you need the latest feature before they are published in an official release.
See [guidelines](./guidelines.html) for the branching workflow used in Rugged.
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://gitlab.orekit.org/orekit/rugged/tree/develop)
tab in Rugged Gitlab.
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 clone it anonymously with the command:
git clone -b develop https://gitlab.orekit.org/orekit/rugged.git
git clone https://www.orekit.org/git/rugged-main.git
* if you are a committer, you can clone it using your ssh credentials with the command:
If you are a committer, you can clone it using your ssh credentials with the command:
git clone -b develop git@gitlab.orekit.org:orekit/rugged.git
git clone ssh://git@www.orekit.org/rugged-main.git
[Top of the page](#top)
src/site/markdown/tutorials/direct-location-with-DEM.md
View file @ acf902ea
<!--- Copyright 2013-2016 CS Systèmes d'Information
<!--- Copyright 2013-2022 CS GROUP
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
......@@ -12,9 +12,13 @@
limitations under the License.
-->
<a name="top"></a>
# Direct Location with a DEM
The aim of this tutorial is to compute a direct location grid by intersection of the line of sight with a DEM (Digital Elevation Model), using Duvenhage's algorithm. This algorithm is the most performant one in Rugged.
The aim of this tutorial is to compute a direct location grid by intersection of
the line of sight with a DEM (Digital Elevation Model), using Duvenhage's algorithm.
This algorithm is the most performant one in Rugged.
The following figure shows the effects of taking into account the DEM in the computation of latitude, longitude and altitude:
......@@ -22,16 +26,32 @@ The following figure shows the effects of taking into account the DEM in the com
## Feeding Rugged with DEM tiles
Rugged does not parse DEM files but takes buffers of elevation data as input. It is up to the calling application to read the DEM and load the data into buffers. Rugged provides a tile mecanism with cache for large DEMs allowing the user to load one tile at a time. This is in line with the format of world coverage DEMs such as SRTM. Rugged offers an interface for updating the DEM tiles in cache with a callback function triggered everytime a coordinate falls outside the current region.
Rugged does not parse DEM files but takes buffers of elevation data as input.
It is up to the calling application to read the DEM and load the data into buffers.
Rugged provides a tile mecanism with cache for large DEMs allowing the user to load
one tile at a time. This is in line with the format of world coverage DEMs such as SRTM.
Rugged offers an interface for updating the DEM tiles in cache with a callback function
triggered everytime a coordinate falls outside the current region.
The calling application must implement the callback function for loading the tiles. We recommend to use GDAL (http://www.gdal.org/) to parse the DEM files as it handles most formats (including geoTIFF for Aster DEM or DTED for SRTM). Rugged does not include the parsing of the DEM, by design, and yet we could have used GDAL. We want Rugged to remain a low-level library that does not pull too many third-party libraries.
The calling application must implement the callback function for loading the tiles.
We recommend to use GDAL (http://www.gdal.org/) to parse the DEM files as it handles most
formats (including geoTIFF for Aster DEM or DTED for SRTM). Rugged does not include the
parsing of the DEM, by design, and yet we could have used GDAL.
We want Rugged to remain a low-level library that does not pull too many third-party libraries.
### Implementing the interface TileUpdater for DEM loading.
In this tutorial, we will not include real DEM data. Instead we are going to create a fake DEM representing a volcano in a form of a perfect cone, similar to the Mayon volcano in the Philippines, except that we will locate it somewhere just below our satellite. This example is already part of Rugged tests cases, the source code is available in the package `org.orekit.rugged.raster`, file VolcanicConeElevationUpdater.java.
In this tutorial, we will not include real DEM data. Instead we are going to create a fake DEM
representing a volcano in a form of a perfect cone, similar to the Mayon volcano
in the Philippines, except that we will locate it somewhere just below our satellite.
This example is already part of Rugged tests cases, the source code is available
in the package `org.orekit.rugged.raster`, file VolcanicConeElevationUpdater.java.
The class `VolcanicConeElevationUpdater` implements the interface `TileUpdater` with its method `updateTile`. The method is in charge of loading a tile. The extent of the tile must be such that it covers at least the ground point with coordinates (latitude, longitude) which are passed as arguments to the method. The tile is an object of type `UpdatableTile` which has two methods :
The class `VolcanicConeElevationUpdater` implements the interface `TileUpdater` with its method `updateTile`.
The method is in charge of loading a tile. The extent of the tile must be such that it covers
at least the ground point with coordinates (latitude, longitude) which are passed as arguments to the method.
The tile is an object of type `UpdatableTile` which has two methods :
* `setGeometry(minLatitude, minLongitude, latitudeStep, longitudeStep, latitudeRows, longitudeRows)` : initializes the extent of the new tile before loading
......@@ -39,7 +59,7 @@ The class `VolcanicConeElevationUpdater` implements the interface `TileUpdater`
Here's the source code of the class `VolcanicConeElevationUpdater` :
import org.hipparchus.util.FastMath;
import org.hipparchus.util.FastMath;
import org.orekit.rugged.raster.TileUpdater;
import org.orekit.rugged.raster.UpdatableTile;
import org.orekit.bodies.GeodeticPoint;
......@@ -88,7 +108,7 @@ import org.hipparchus.util.FastMath;
### Important notes on DEM tiles :
* Ground point elevation are obtained by bilinear interpolation between 4 neighbouring cells. There is no specific algorithm for border management. As a consequence, a point falling on the border of the tile is considered outside. DEM tiles must be overlapping by at least one line/column in all directions, in a similar way as for the SRTM DEMs.
* Ground point elevation are obtained by bilinear interpolation between 4 neighbouring cells. There is no specific algorithm for border management. As a consequence, a point falling on the border of the tile is considered outside. **DEM tiles must be overlapping by at least one line/column in all directions**.
* In Rugged terminology, the minimum latitude and longitude correspond to the centre of the farthest Southwest cell of the DEM. Be careful if using GDAL to pass the correct information as there is half a pixel shift with respect to the lower left corner coordinates in gdalinfo.
......@@ -102,7 +122,8 @@ This diagram tries to represent the meaning of the different parameters in the d
## Initializing Rugged with a DEM
The initialization step differs slightly from the first tutorial [Direct location](direct-location.html), as we need to pass the information about our TileUpdater.
The initialization step differs slightly from the first tutorial [Direct location](./direct-location.html),
as we need to pass the information about our TileUpdater.
Instantiate an object derived from TileUpdater :
......@@ -127,7 +148,8 @@ Initialize Rugged with these parameters :
## Computing a direct location grid
In a similar way as in the first tutorial [DirectLocation](./direct-location.html), we call Rugged direct location method. This time it is called in a loop so as to generate a full grid on disk.
In a similar way as in the first tutorial [Direct Location](./direct-location.html),
we call Rugged direct location method. This time it is called in a loop so as to generate a full grid on disk.
DataOutputStream dos = new DataOutputStream(new FileOutputStream("demDirectLoc.c1"));
int lineStep = (maxLine - minLine) / nbLineStep;
......@@ -169,4 +191,6 @@ In a similar way as in the first tutorial [DirectLocation](./direct-location.htm
}
## Source code
The source code is available in DirectLocationWithDEM.java
The source code is available in DirectLocationWithDEM.java (package fr.cs.examples under src/tutorials)
[Top of the page](#top)
src/site/markdown/tutorials/direct-location.md
View file @ acf902ea
<!--- Copyright 2013-2016 CS Systèmes d'Information
<!--- Copyright 2013-2022 CS GROUP
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
......@@ -12,6 +12,8 @@
limitations under the License.
-->
<a name="top"></a>
# Rugged initialization and direct location
This tutorial explains how to initialize Rugged and use it to geolocate a satellite image.
......@@ -21,7 +23,7 @@ list of positions, velocities and attitude quaternions recorded during the acqui
passing all this information to Rugged, we will be able to precisely locate each point of
the image on the Earth. Well, not exactly precise, as this first tutorial does not use a
Digital Elevation Model, but considers the Earth as an ellipsoid. The DEM will be added in
a second tutorial: [Direct location with a DEM](direct-location-with-DEM.html). The objective
a second tutorial: [Direct location with a DEM](./direct-location-with-DEM.html). The objective
here is limited to explain how to initialize everything Rugged needs to know about the sensor
and the acquisition.
......@@ -55,7 +57,7 @@ The raw viewing direction of pixel i with respect to the instrument is defined b
List<Vector3D> rawDirs = new ArrayList<Vector3D>();
for (int i = 0; i < 2000; i++) {
//20° field of view, 2000 pixels
// 20° field of view, 2000 pixels
rawDirs.add(new Vector3D(0d, i*FastMath.toRadians(20)/2000d, 1d));
}
......@@ -127,9 +129,9 @@ which frames we are using and convert if necessary.
Conversion from inertial to Earth-rotating frame is transparent to the user and is based on the most
recent precession/nutation model on top of which corrections published by the IERS are applied. IERS
bulletins and other physical data are provided within the orekit-data folder. There are several ways
bulletins and other physical data are provided within the orekit data folder. There are several ways
to configure Orekit to use this data. More information is given
[here](https://www.orekit.org/forge/projects/orekit/wiki/Configuration).
[here](../configuration.html)
In our application, we simply need to know the name of the frames we are working with. Positions and
velocities are given in the ITRF terrestrial frame, while the quaternions are given in EME2000
......@@ -161,7 +163,7 @@ Each attitude sample (quaternion, time) is added to the list,
where, for instance, gpsDateAsString is set to "2009-12-11T10:49:55.899994"
### Position and velocities
### Positions and velocities
Similarly the positions and velocities will be set in a list of `TimeStampedPVCoordinates`. Before being
......@@ -224,7 +226,7 @@ Elevation Model in this tutorial, we could have omitted this call and it would h
We preferred to let it in so users do not forget to set the Digital Elevation Model for intersection
algorithms that really use them. As the model will be ignored, we can put the parameters for this
setter to `null` and `0`. Of course if another algorithm had been chosen, null parameters would clearly
not work, this is explained in another tutorial: [Direct location with a DEM](direct-location-with-DEM.html).
not work, this is explained in another tutorial: [Direct location with a DEM](./direct-location-with-DEM.html).
The *setEllipsoid* setter defines the shape and orientation of the ellipsoid. We use simple predefined enumerates:
`EllipsoidId.WGS84`, `InertialFrameId.EME2000`, but could also use a custom ellipsoid if needed.
......@@ -307,11 +309,19 @@ Finally everything is set to do some real work. Let's try to locate a point on E
for upper left point (first line, first pixel):
import org.orekit.bodies.GeodeticPoint;
Vector3D position = lineSensor.getPosition(); // This returns a zero vector since we set the relative position of the sensor w.r.T the satellite to 0.
Vector3D position = lineSensor.getPosition(); // This returns a zero vector since we set the relative position of the sensor w.r.t. the satellite to 0.
AbsoluteDate firstLineDate = lineSensor.getDate(0);
Vector3D los = lineSensor.getLOS(firstLineDate, 0);
GeodeticPoint upLeftPoint = rugged.directLocation(firstLineDate, position, los);
The line number can have negative values; the associated date must belong to the time span given when building Rugged with setTimeSpan(acquisitionStartDate, acquisitionStopDate,...).
Otherwise a RuggedException will be thrown.
The pixel number must be given between 0 and the (Sensor pixel size – 1); in our example between 0 and 1999.
Otherwise an ArrayIndexOutOfBoundsException will be thrown.
## Source code
The source code is available in DirectLocation.java
The source code is available in DirectLocation.java (package fr.cs.examples under src/tutorials)
[Top of the page](#top)
src/site/markdown/tutorials/inverse-location.md
View file @ acf902ea
<!--- Copyright 2013-2016 CS Systèmes d'Information
<!--- Copyright 2013-2022 CS GROUP
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
......@@ -12,33 +12,42 @@
limitations under the License.
-->
<a name="top"></a>
# Inverse Location
The aim of this tutorial is to compute the inverse location of a point on Earth in order to give the sensor pixel, with the associated line, seeing this point.
The aim of this tutorial is to compute the inverse location of a point on Earth
in order to give the sensor pixel, with the associated line, seeing this point.
We will also explain how to find the date at which sensor sees a ground point, which is a kind of inverse location only focusing on date.
We will also explain how to find the date at which sensor sees a ground point,
which is a kind of inverse location only focusing on date.
## Inverse location of a point on Earth
The initialisation of Rugged is similar as in the [Direct location](direct-location.html) tutorial up to the addition of the lines sensor.
The initialization of Rugged is similar as in the [Direct location](./direct-location.html) tutorial up to rugged initialization..
### Point defined by its latitude, longitude and altitude
Once Rugged initialised, one can compute the line number and the pixel number of a point defined by its Geodetic coordinates:
Once Rugged initialized, one can compute the line number and the pixel number of a point defined by its Geodetic coordinates:
import org.orekit.bodies.GeodeticPoint;
import org.orekit.rugged.linesensor.SensorPixel;
GeodeticPoint gp = new GeodeticPoint(latitude, longitude, altitude);
SensorPixel sensorPixel = rugged.inverseLocation(sensorName, gp, minLine, maxLine);
where minLine (maxLine, respectively) is the minimum line number for the search interval (maximum line number, respectively).
The inverse location will give the sensor pixel number and the associated line number seeing the point. In case the point cannot be seen between the prescribed line numbers, the return result is null. No exception will be thrown in this particular case.
The inverse location will give the sensor pixel number and the associated line number
seeing the point on ground.
**In case the point cannot be seen between the prescribed line numbers, the return result is null.
No exception will be thrown in this particular case**.
### Point defined by its latitude and longitude (no altitude)
Similarly, one can compute the line number and the pixel number of a point defined solely by its latitude en longitude. The altitude will be determined automatically with the DEM.
Similarly, one can compute the line number and the pixel number of a point defined solely
by its latitude en longitude. The altitude will be determined automatically with the DEM.
SensorPixel sensorPixel = rugged.inverseLocation(sensorName, latitude, longitude, minLine, maxLine);
## Date location
Once Rugged initialised, one can compute the date at which sensor sees a point on Earth.
Once Rugged initialized, one can compute the date at which sensor sees a point on Earth.
### Point defined by its latitude, longitude and altitude
For a point defined by its Geodetic coordinates:
......@@ -50,5 +59,31 @@ Similarly, for a point defined solely by its latitude en longitude (altitude det
AbsoluteDate dateLine = rugged.dateLocation(sensorName, latitude, longitude, minLine, maxLine);
## Determine the min/max lines interval
Rugged provides a way to determine a **very** rough estimation of the line using only
the position-velocities of the satellite. It assumes the position-velocities are regular enough and without holes.
OneAxisEllipsoid oneAxisEllipsoid = ruggedBuilder.getEllipsoid();
Frame pvFrame = ruggedBuilder.getInertialFrame();
RoughVisibilityEstimator roughVisibilityEstimator= new RoughVisibilityEstimator(oneAxisEllipsoid, pvFrame, satellitePVList);
One can compute the approximated line with the rough visibility estimator:
AbsoluteDate roughLineDate = roughVisibilityEstimator.estimateVisibility(gp);
double roughLine = lineSensor.getLine(roughLineDate);
The result will never be null, but may be really far from reality if ground point is away from trajectory.
With this rough line, taken some margin around (for instance 100), one can initialize
the min/max lines as search boundaries for inverse location, taken into account sensor min and max lines:
int minLineRough = (int) FastMath.max(FastMath.floor(roughLine - margin), sensorMinLine);
int maxLineRough = (int) FastMath.min(FastMath.floor(roughLine + margin), sensorMaxLine);
then one can compute the inverse location:
SensorPixel sensorPixel = rugged.inverseLocation(sensorName, gp, minLineRough, maxLineRough);
## Source code
The source code is available in InverseLocation.java
The source code is available in InverseLocation.java (package fr.cs.examples under src/tutorials)
[Top of the page](#top)
src/site/markdown/tutorials/matlab-example.md 0 → 100644
View file @ acf902ea
<!--- Copyright 2013-2022 CS GROUP
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.
-->
# Calling Rugged from Matlab
Examples of direct and inverse location were provided by the Centre de Techniques Spatiales of the Algerian Space Agency.
Under `src/site/resources/sources/matlab-examples/` :
* Direct location: `DirectLocation.m`
* Inverse location: `InverseLocation.m`
* Function to parse a DIMAP file: `dim2rugged.m`
If you have any question about the examples, please contact issam.boukerch@yahoo.fr, researcher at the CTS.
src/site/markdown/tutorials/tile-updater.md
View file @ acf902ea
<!--- Copyright 2013-2016 CS Systèmes d'Information
<!--- Copyright 2013-2022 CS GROUP
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
......
src/site/resources/images/logo_cs_2008_baseline_ang.jpg deleted 100644 → 0
View file @ 950e0db2
src/site/resources/images/logo_cs_2008_baseline_ang.jpg

31.6 KiB

src/site/resources/images/logo_cs_group.png 0 → 100644
View file @ acf902ea
src/site/resources/images/logo_cs_group.png

19.1 KiB

src/site/resources/images/orekit-logo.png
View replaced file @ 950e0db2 View file @ acf902ea
src/site/resources/images/orekit-logo.png

11.3 KiB | W: 0px | H: 0px

src/site/resources/images/orekit-logo.png

21.4 KiB | W: 0px | H: 0px

src/site/resources/images/orekit-logo.png
src/site/resources/images/orekit-logo.png
src/site/resources/images/orekit-logo.png
src/site/resources/images/orekit-logo.png
  • 2-up
  • Swipe
  • Onion skin
src/site/resources/images/rugged-architecture.odg 0 → 100644
View file @ acf902ea
File added
src/site/resources/images/rugged-architecture.png
View replaced file @ 950e0db2 View file @ acf902ea
src/site/resources/images/rugged-architecture.png

27.9 KiB | W: 0px | H: 0px

src/site/resources/images/rugged-architecture.png

35.5 KiB | W: 0px | H: 0px

src/site/resources/images/rugged-architecture.png
src/site/resources/images/rugged-architecture.png
src/site/resources/images/rugged-architecture.png
src/site/resources/images/rugged-architecture.png
  • 2-up
  • Swipe
  • Onion skin
src/site/resources/images/rugged-git-flow.odg 0 → 100644
View file @ acf902ea
File added
src/site/resources/images/rugged-git-flow.png 0 → 100644
View file @ acf902ea
src/site/resources/images/rugged-git-flow.png

43.3 KiB

src/site/resources/images/rugged-logo-small.jpg 0 → 100644
View file @ acf902ea
src/site/resources/images/rugged-logo-small.jpg

13.4 KiB

src/site/resources/images/rugged-logo.jpg 0 → 100644
View file @ acf902ea
src/site/resources/images/rugged-logo.jpg

48.6 KiB