Orekit issueshttps://gitlab.orekit.org/orekit/orekit/-/issues2019-07-05T17:42:40Zhttps://gitlab.orekit.org/orekit/orekit/-/issues/538Problem with method ComparableMeasurement.compareTo()2019-07-05T17:42:40ZDorian GegoutProblem with method ComparableMeasurement.compareTo()It seems there is a bug the method ComparableMeasurement.compareTo() which allow violation of the transitivity rule. Further details are explained on https://forum.orekit.org/t/problem-with-method-comparablemeasurement-compareto/438It seems there is a bug the method ComparableMeasurement.compareTo() which allow violation of the transitivity rule. Further details are explained on https://forum.orekit.org/t/problem-with-method-comparablemeasurement-compareto/43810.0https://gitlab.orekit.org/orekit/orekit/-/issues/529Attitude transitions in analytical propagators2019-07-05T17:42:40ZMirco RasottoAttitude transitions in analytical propagatorsWhen trying to use the attitude sequence with an Ephemeris object, an OUT_OF_RANGE_SIMPLE exception is thrown.When trying to use the attitude sequence with an Ephemeris object, an OUT_OF_RANGE_SIMPLE exception is thrown.10.0https://gitlab.orekit.org/orekit/orekit/-/issues/528getClockCorrection from SP3File returns value in megaseconds2019-07-05T17:42:39ZGowtham SivaramangetClockCorrection from SP3File returns value in megasecondsWhen trying to load clock corrections value using `SP3Parser` from an sp3 file, the value returned by `getClockCorrection` is in megaseconds, although the document specifies seconds.
During parsing of SP3 file, `latestClock` is multipl...When trying to load clock corrections value using `SP3Parser` from an sp3 file, the value returned by `getClockCorrection` is in megaseconds, although the document specifies seconds.
During parsing of SP3 file, `latestClock` is multiplied by 1E6 instead of 1E-6. Similarly issue exists for `clockRateChange` also.10.0https://gitlab.orekit.org/orekit/orekit/-/issues/526Remove private class BilinearInterpolatingFunction into Saastamoinen model2019-07-05T17:42:39ZBryan CazabonneRemove private class BilinearInterpolatingFunction into Saastamoinen modelBilinearInterpolatingFunction is available into Hipparchus since release 1.4. Hence, it is possible to replace the private class BilinearInterpolatingFunction of the Saastamoinen model by the one of Hipparchus.BilinearInterpolatingFunction is available into Hipparchus since release 1.4. Hence, it is possible to replace the private class BilinearInterpolatingFunction of the Saastamoinen model by the one of Hipparchus.10.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/507Add Action.RESET_EVENTS2019-07-05T17:42:38ZEvan WardAdd Action.RESET_EVENTSAdd an event action that tells the propagator to recheck all event detectors for occurring events.
See the discussion in https://forum.orekit.org/t/eventdetection-based-on-time-in/293Add an event action that tells the propagator to recheck all event detectors for occurring events.
See the discussion in https://forum.orekit.org/t/eventdetection-based-on-time-in/29310.0https://gitlab.orekit.org/orekit/orekit/-/issues/556Coverage results not taken into account in the CI build status2019-07-05T17:42:38ZSébastien Dinotsebastien.dinot@csgroup.euCoverage results not taken into account in the CI build statusThe CI build status of [Build #127](https://ci.orekit.org/job/orekit/job/develop/127/) displayed by Jenkins is "Success" (blue bullet) despite that the coverage ratios are under the required values:
* Class: 99 % instead of 100 %
* Meth...The CI build status of [Build #127](https://ci.orekit.org/job/orekit/job/develop/127/) displayed by Jenkins is "Success" (blue bullet) despite that the coverage ratios are under the required values:
* Class: 99 % instead of 100 %
* Method: 93 % instead of 95 %
The CI tool should warn developers against such deviation and display a different result (yellow or red bullet depending on the coverage ratios are under "maximum<Counter>Coverage" or "minimun<Counter>Coverage").10.0https://gitlab.orekit.org/orekit/orekit/-/issues/551AttitudeSequence transition not computed with analytical propagators2019-07-05T17:42:37ZRomaric HERAttitudeSequence transition not computed with analytical propagatorsIn the case of an attitude transition is triggered by an event detector during an analytical propagation, the attitude of the satellite is not correctly computed if the beginning of the propagation is before the transition and the end of...In the case of an attitude transition is triggered by an event detector during an analytical propagation, the attitude of the satellite is not correctly computed if the beginning of the propagation is before the transition and the end of the propagation is after the transition.
The origin of the bug is : the final SpacecraftState is computed before the event triggering, but the attitude transition is computed only after the events triggering. So the returned SpacecraftState is computed with the initial attitude law, not the updated one after the transition.10.0Romaric HERRomaric HERhttps://gitlab.orekit.org/orekit/orekit/-/issues/552AttitudeSequence bug when the propagation ends and restart during the transit...2019-07-05T17:42:37ZRomaric HERAttitudeSequence bug when the propagation ends and restart during the transition periodIn case of multiple uses of the propagate method with an attitude sequence, if one use of propagate method ends in the transition period an another one starts during the transition period, the attitude after the transition is not correct...In case of multiple uses of the propagate method with an attitude sequence, if one use of propagate method ends in the transition period an another one starts during the transition period, the attitude after the transition is not correct.
This is due to the fact that each use of the propagate method reset the events detector, that reset the TimeSpanMap used in the AttitudeSequence object. The reset will cause that the map that is supposed to describe the "after" attitude law is deleted by the reset, since the current date is still in the transition period. But the transition event is already in the past so the "after" attitude law will not be computed again. The attitude law is stuck in the transition phase and returns wrong values.10.0Romaric HERRomaric HERhttps://gitlab.orekit.org/orekit/orekit/-/issues/550Download url of the latest Orekit archives not provided in technical document...2019-07-05T17:42:37ZSébastien Dinotsebastien.dinot@csgroup.euDownload url of the latest Orekit archives not provided in technical documentationDownload url of the latest Orekit archives not provided in the technical documentation generated by Maven:
<https://www.orekit.org/site-orekit-9.3.1/downloads.html>
---
| package | link ...Download url of the latest Orekit archives not provided in the technical documentation generated by Maven:
<https://www.orekit.org/site-orekit-9.3.1/downloads.html>
---
| package | link |
|----------|---------------------------------------------------------------------|
| source | orekit-9.3.1-sources.zip (URL to be defined after official release) |
| binary | orekit-9.3.1.jar (URL to be defined after official release) |
version 9.3.1 downloads (release date: 2019-03-16)
---10.0https://gitlab.orekit.org/orekit/orekit/-/issues/553AttitudeSequence bug with Ephemeris propagator2019-07-05T17:42:36ZRomaric HERAttitudeSequence bug with Ephemeris propagatorIn case of an attitude transition during an propagation with Ephemeris, a "OUT_OF_RANGE_SIMPLE" exception will be thrown.
This is due to a check in the getPVCoordinates method of Ephemeris, that will check that the current date is the s...In case of an attitude transition during an propagation with Ephemeris, a "OUT_OF_RANGE_SIMPLE" exception will be thrown.
This is due to a check in the getPVCoordinates method of Ephemeris, that will check that the current date is the same as the computed state date. In case of an attitude transition, if we try to compute the attitude during the transition period, the propagator needs the attitude at the end of this period, so this check will fail.10.0Romaric HERRomaric HERhttps://gitlab.orekit.org/orekit/orekit/-/issues/545.mailmap file is out of date2019-07-05T17:42:36ZSébastien Dinotsebastien.dinot@csgroup.eu.mailmap file is out of dateThe [.mailmap](https://gitlab.orekit.org/orekit/orekit/blob/develop/.mailmap) file is quite out of date. As it stands, Orekit seems to have been developed by 49 different people, but in reality, the project has only 33 contributors.
The...The [.mailmap](https://gitlab.orekit.org/orekit/orekit/blob/develop/.mailmap) file is quite out of date. As it stands, Orekit seems to have been developed by 49 different people, but in reality, the project has only 33 contributors.
The merge request !4 is proposed to fix this issue.10.0https://gitlab.orekit.org/orekit/orekit/-/issues/539Deprecated day of year computation in DTM2000 model.2019-07-05T17:42:36ZMaxime JournotDeprecated day of year computation in DTM2000 model.DTM2000 atmosphere class uses Java class GregorianCalendar in method [getDensity](https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/forces/drag/atmosphere/DTM2000.java#L333) to compute the day of year.
No Tim...DTM2000 atmosphere class uses Java class GregorianCalendar in method [getDensity](https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/forces/drag/atmosphere/DTM2000.java#L333) to compute the day of year.
No TimeZone is provided so that the default TimeZone is used. Default TimeZone depends on user's machine so it can be different than "GMT+00".
Day of year computation should not be dependent on user's default time zone.
Method [DateComponents.getDayOfYear](https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/time/DateComponents.java#L447) should be used instead (as in [NRLMSIS00.getDensity](https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/forces/drag/atmosphere/NRLMSISE00.java#L1127)).10.0https://gitlab.orekit.org/orekit/orekit/-/issues/544Infinite loop on GPSPropagator and (Field)KeplerianOrbit2019-07-05T17:42:35ZBryan CazabonneInfinite loop on GPSPropagator and (Field)KeplerianOrbitA pull request has been open on the Orekit GitHub repository ([here](https://github.com/CS-SI/Orekit/pull/21#issuecomment-489652905)). It is related to an endless loop when `x.getValue()` or `x0.getValue()` is Double.NaN on GPSPropagator...A pull request has been open on the Orekit GitHub repository ([here](https://github.com/CS-SI/Orekit/pull/21#issuecomment-489652905)). It is related to an endless loop when `x.getValue()` or `x0.getValue()` is Double.NaN on GPSPropagator class. This endless loop can also occur on KeplerianOrbit and FieldKeplerianOrbit classes.10.0https://gitlab.orekit.org/orekit/orekit/-/issues/541README enhancement2019-07-05T17:42:35ZSébastien Dinotsebastien.dinot@csgroup.euREADME enhancementIn my humble opinion, the [README file](https://gitlab.orekit.org/orekit/orekit/blob/master/README.txt) provided with Orekit source code is totally old-fashioned:
* It uses the plain text format rather than a lightweight markup language...In my humble opinion, the [README file](https://gitlab.orekit.org/orekit/orekit/blob/master/README.txt) provided with Orekit source code is totally old-fashioned:
* It uses the plain text format rather than a lightweight markup language such as [Markdown](https://daringfireball.net/projects/markdown/) or [reStructuredText](http://docutils.sourceforge.net/rst.html).
* It is poor in information (no indication is provided, for example, on how to contribute, or how to report a bug).
Several initiatives have attempted to list good practices regarding the content of a README file and/or to provide README templates:
* [Readme Best Practices](https://github.com/jehna/readme-best-practices)
* [Art of README](https://github.com/noffle/art-of-readme)
I think that Orekit merits such modern README file.10.0https://gitlab.orekit.org/orekit/orekit/-/issues/389Change type parameter of AbstractDetector to T extends AbstractDetector<T>2019-07-05T17:41:54ZEvan WardChange type parameter of AbstractDetector to T extends AbstractDetector<T>If the user knows they have an AbstractDetector, they should be able to
call the withXxx methods any number of times.
Currently the following fails to compile because the type returned by
the withXxx() methods is an EventDetector
\`\`...If the user knows they have an AbstractDetector, they should be able to
call the withXxx methods any number of times.
Currently the following fails to compile because the type returned by
the withXxx() methods is an EventDetector
\`\`\`
AbstractDetector<?>d = ...;
d.withMaxIter(9).withMaxIter(9);
\`\`\`
To call the with methods multiple times you have replace \`?\` with \`?
extends AbstractDetector<?>\` once for each time you plan to call
a with method. Clearly this does not scale well and is bad API design.
Changing the declaration of AbstractDetector to
\`AbstractDetector<T extends AbstractDetector<T>>\` would solve the
issue and allow the earlier example to compile.
This change is backwards incompatible, so I'm making a note of it here
util we are ready to include it.
*(from redmine: issue id 389, created on 2018-03-07)*10.0https://gitlab.orekit.org/orekit/orekit/-/issues/521Add BeiDou Propagator2019-07-05T17:41:53ZBryan CazabonneAdd BeiDou PropagatorSame as issue #519 and #520 but for BeiDou satellites.
Steps of computation are detailed into [BeiDou Interface Control Document](http://en.beidou.gov.cn/SYSTEMS/Officialdocument/201806/P020180608525875134604.pdf)Same as issue #519 and #520 but for BeiDou satellites.
Steps of computation are detailed into [BeiDou Interface Control Document](http://en.beidou.gov.cn/SYSTEMS/Officialdocument/201806/P020180608525875134604.pdf)10.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/527SI base unit API for magnetic field model2019-07-05T17:41:53ZBryan CazabonneSI base unit API for magnetic field modelCurrent API for magnetic field model is not in SI base unit. Magnetic field is computed using latitude and longitude in degrees and height in kilometers as input parameters. Furthermore, `getDeclination()` and `getInclination()` methods ...Current API for magnetic field model is not in SI base unit. Magnetic field is computed using latitude and longitude in degrees and height in kilometers as input parameters. Furthermore, `getDeclination()` and `getInclination()` methods in `GeoMagneticElements.java` class return angles in degree unit. API has to be change to consider angles in radians and height in meters.10.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/519Add GLONASS Propagator2019-07-05T17:41:53ZBryan CazabonneAdd GLONASS PropagatorAs it is already done in Orekit for GPS orbits, it can be interesting to add a Glonass propagator to convert Glonass almanac data to position and velocity vector components.
Steps of computation are present into [GLONASS Interface Contr...As it is already done in Orekit for GPS orbits, it can be interesting to add a Glonass propagator to convert Glonass almanac data to position and velocity vector components.
Steps of computation are present into [GLONASS Interface Control Document](http://gauss.gge.unb.ca/GLONASS.ICD.pdf)10.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/522Add QZSS Propagator2019-07-05T17:41:53ZBryan CazabonneAdd QZSS PropagatorSee issues #519 #520 #521
Steps of computation are available on the [QZSS Interface Specification](http://qzss.go.jp/en/technical/download/pdf/ps-is-qzss/is-qzss-pnt-003.pdf?t=1549268771755)See issues #519 #520 #521
Steps of computation are available on the [QZSS Interface Specification](http://qzss.go.jp/en/technical/download/pdf/ps-is-qzss/is-qzss-pnt-003.pdf?t=1549268771755)10.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/531Remove TroposphericModel interface2019-07-05T17:41:52ZBryan CazabonneRemove TroposphericModel interfaceSince Orekit 9.3, a new interface is available for tropospheric models (`DiscreteTroposphericModel`).
Because of compatibility issues, we did not delete the interface `TroposphericModel` for Orekit 9.3 release. Major release allowing API...Since Orekit 9.3, a new interface is available for tropospheric models (`DiscreteTroposphericModel`).
Because of compatibility issues, we did not delete the interface `TroposphericModel` for Orekit 9.3 release. Major release allowing API changes it is possible for Orekit 10.0 release to delete this interface. Implementations of the old interface `TroposphericModel` should now implement `DiscreteTroposphericModel`.10.0Bryan CazabonneBryan Cazabonne