Orekit issueshttps://gitlab.orekit.org/orekit/orekit/-/issues2019-07-05T17:41:52Zhttps://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 Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/530Removing Serializable for events detectors and attitude providers2019-06-14T20:00:01ZLuc MaisonobeRemoving Serializable for events detectors and attitude providersAs per discussion [https://forum.orekit.org/t/removing-serializable-for-events-detectors-and-perhaps-attitude-providers/403](https://forum.orekit.org/t/removing-serializable-for-events-detectors-and-perhaps-attitude-providers/403), seria...As per discussion [https://forum.orekit.org/t/removing-serializable-for-events-detectors-and-perhaps-attitude-providers/403](https://forum.orekit.org/t/removing-serializable-for-events-detectors-and-perhaps-attitude-providers/403), serialization should be removed for at least event detectors and attitude providers.10.0Luc MaisonobeLuc Maisonobehttps://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/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/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/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/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/520Add Galileo Propagator2019-07-05T17:41:52ZBryan CazabonneAdd Galileo PropagatorSame as issue #519 but for Galileo almanacs.
Steps of computations are available into [Galileo Interface Control Document](https://www.gsc-europa.eu/system/files/galileo_documents/Galileo-OS-SIS-ICD.pdf)Same as issue #519 but for Galileo almanacs.
Steps of computations are available into [Galileo Interface Control Document](https://www.gsc-europa.eu/system/files/galileo_documents/Galileo-OS-SIS-ICD.pdf)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/518AbstractGNSSAttitudeProvider should be private package2019-07-05T17:41:50ZPetrus HyvönenAbstractGNSSAttitudeProvider should be private packageThe AbstractGNSSAttitudeProvider is not usable outside the attitude package and was not intented (ref Luc) for public usage. This package should thus be set private.The AbstractGNSSAttitudeProvider is not usable outside the attitude package and was not intented (ref Luc) for public usage. This package should thus be set private.10.0https://gitlab.orekit.org/orekit/orekit/-/issues/514Deprecate then delete unused DerivativeStructure acceleration computation met...2019-07-05T17:41:52ZMaxime JournotDeprecate then delete unused DerivativeStructure acceleration computation methodsSome methods computing `FieldVector3D<DerivativeStructure>` acceleration and using a parameter name as input should have been deleted in version 9.0 but were left over.
They should be deemed `@Deprecated` in version 9.3 and then deleted ...Some methods computing `FieldVector3D<DerivativeStructure>` acceleration and using a parameter name as input should have been deleted in version 9.0 but were left over.
They should be deemed `@Deprecated` in version 9.3 and then deleted in version 10.0.
These methods are:
- `FieldVector3D<DerivativeStructure> dragAcceleration` in interface [DragSensitive](https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/forces/drag/DragSensitive.java#L117) and all its implementations;
- `FieldVector3D<DerivativeStructure> radiationPressureAcceleration` in [RadiationSensitive](https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/forces/radiation/RadiationSensitive.java#L90) and all its implementations
Related tests should also be deprecated then deleted.10.0https://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/506Delete FieldEventHandler.Action2019-07-05T17:41:50ZEvan WardDelete FieldEventHandler.Action`FieldEventHandler.Action` just duplicates `EventHandler.Action` without adding any field specific behavior or information. Remove the duplicate enum and just use `EventHandler.Action`. It may be worth moving `Action` to a top level type...`FieldEventHandler.Action` just duplicates `EventHandler.Action` without adding any field specific behavior or information. Remove the duplicate enum and just use `EventHandler.Action`. It may be worth moving `Action` to a top level type to clarify it can be used for field and non-field event detectors. Hipparchus only uses one Action enum for both double and Field ODEs. This change will break backward compatibility, so it should wait until the next major release.
Other option is to delete both of Orekit's Action enums and just use Action from Hipparchus since they must all define the same values for Orekit to work correctly.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.0